OS/2 Shareware BBS: 29 Fixes

home *** CD-ROM | disk | FTP | other *** search

/ OS/2 Shareware BBS: 29 Fixes_o / 29-Fixes_o.zip / ur458017.dsk / R2T1REL.TXT < prev next >

Wrap

Text File | 1995-07-26 | 65KB | 1,283 lines

Release Note & Implementation Guide for R2T1 V4.4 24-03-95 Aculab Ltd 1 Introduction and Scope This release note considers the use of the Aculab ISDN/E1 card with the Generic MFC R2 Signalling System 'R2T1', and the impli- cations for the applications programmer. This document is only intended to be a guide to implementation and is not intended to be an exhaustive description of the API; see the Generic API Specification documents for full details. It should be noted that many of the features illustrated here were only introduced along with the Release 3 of Aculab device drivers, and are not available with any previous release, and indeed the R2T1 signal- ling protocol is not supported by any device driver prior to Release 3. Information for this implementation of R2 was taken from both the CCITT Blue Book, a collection of Ericsson specification docu- ments, and a multitude of National signalling specifications. For the purposes of illustration, this document uses the EV_xxx (event) scheme provided by the E1 card API to describe various telephony issues, but the state based (CS_xxx) approach is equal- ly valid. 2 New Functionality in Version 4 Version 4 introduces full control of group-B signals on incoming calls, both for call rejection and call acceptance. In addition, it allows recovery of the returned group-B meanings on outgoing calls. These features are supported in a standard (and re- configurable manner) under the API, and are described in a later section. 3 Basic Functionality Outgoing Call Setup, with Destination Address via MFC, DTMF or decadic Overlap Sending (both en-bloc and overlap from the API) Recovery of group B meaning for answer and reject Provision of CLI (Optional) Return of received Charging Pulses (Optional) Call Release Remote Disconnect on Release (Optional) Incoming Call Accept, with DDI digits via MFC, DTMF or decadic Request of CLI (Optional) Internal Generation of alternate Ring Tone cadences (Opt) External Generation of Ring Tone and call progress tones (Opt) Generation of group B meaning for answer and reject Generation of Charging Pulses (Optional) Call Release General Auto Back-Busy on 'not open for incoming' (Optional) Note that this signalling system is balanced, meaning that the same protocol may be used at both ends of a link, for both-way working (although of course, only one end should be sourcing the clock for the link). 4 A Common Issue with Tone-Based Signalling There is one particular issue with MFC R2 that is worth high- lighting, insofar as the tone element of the signalling proceeds within the B-channel, and for this reason, the DSP in the E1 card must remain connected to the line until the tone signalling has completed. It is a common error to attempt to switch the B-channel through to a speech processing resource too early, thus cutting off the final part of the MFC signalling, causing mis-operation. In particular, just issuing the API call call_accept() does not mean the compelled signalling has finished, the application must wait until EV_CALL_CONNECTED (or CS_CALL_CONNECTED) or issue call_incoming_ringing() then wait on EV_WAIT_FOR_ACCEPT (or CS_WAIT_FOR_ACCEPT) before it is safe to switch the B-channels away from the DSP. 5 Dialled Destination Digits In international R2, the first dialled digit(s) may represent language digits or discriminating digits, and these may be pre- pended to the actual destination address. However, some of these signals may require values greater than 1..9 or 10 (the digit '0'), so, if it is required to send the group I signals 11..15, the hexadecimal characters B..F will produce the appropriate forward tones (for the dialled destination digits only, not for the CLI). On receipt, these same hexadecimal values may appear at the front of the incoming destination address (DDI) number. The signal I-15 (which would produce an 'F') is sometimes used as an 'End of Pulsing' signal, to terminate the destination address (B party number). On incoming calls this may recognised as such by the use of the appropriate configuration switch (see below), in which case it will not appear in the incoming destination address. Outgoing destination addresses do not automatically produce I-15 as a termination signal, as this would interfere with the provi- sions for overlap sending, however, an 'F' can be sent as the last dialled digit to achieve the same effect. 6 CLI (Calling Line Identity) The implementation allows the request of CLI information if available, but note that it may or may not be available on ordi- nary lines. On outgoing calls, request of CLI by the called party with no digits supplied via the API will result in generation of an I-12 (request not accepted), although there is a configuration switch to cause an immediate I-15 (end of CLI) to be sent instead. If CLI digits are available, the CLI will normally be preceded with a subscriber category of II-1 (or optionally other group II signals via a configuration switch) and terminated with a I-15 (end of CLI). It is possible, via a configuration switch, to prevent the automatic transmission of the group II signal from within the firmware, in which case the first CLI digit provided via the API will be interpreted as the calling party category, allowing full application program control of this signal. On incoming calls, if CLI is requested of the calling end, and none is available, the implementation will deal with either a no- tone response by subsequently providing a pulsed tone as re- quired, or will accept either an I-12, as a 'request not accep- ted', or I-15 as immediate 'end of CLI'. Accordingly, in connec- tion with CLI, the application should perhaps wait a reasonable time for CLI digits to arrive, and if none arrive, the applica- tion should proceed without them. Also, if no CLI seems ever to be available, it is probably better not to request it at all, in which case no related signalling is produced, and the protocol will proceed in a rather more efficient manner. After request of CLI, care should be taken to ensure that neither call_incoming_ringing or call_accept is called by the application until sufficient time for all of the CLI digits and the subse- quent 'end of CLI' signal to arrive, as pre-empting these with answer will often be regarded as illegal by the central office. A configuration switch is available to prevent these API calls from pre-empting 'end of CLI' and having this effect, but be aware that this will result in a protocol 'lock-up' if the proto- col does not use such an 'end of CLI' signal. Note also that the first digit of the received CLI is often a caller category digit (often a '1') and is not a part of the CLI itself. This character can be automatically stripped off as required by setting one of the configuration switches. 7 CLI and DDI digit count For Aculab's generic R2 device drivers, it is usually useful (and in the case of the Belgian R2, vital) for the device driver and signalling system firmware to know the number of DDI and CLI digits supported by the trunk. There are two driver configura- tion switches available for this purpose, being -cDn and -cCn, where for DDI and CLI respectively, where n is the number of digits required. However, with R2T1 it is NOT absolutely necessary for the driver to know the exact number of digits, particularly for CLI. If the numbers of digits IS known, the signalling code will use the fastest possible compelled signalling to obtain the digits. If it is not known, or is variable, then as long as the numbers given to the driver is LARGER than the maximum number of actual digits, then the signalling system will accept all available digits, at the cost of around a 250mS pulsed tone delay (although if I-15 is used as 'end of CLI', the pulse tone delay will not be incurred). If I-15 is provided 'end of CLI', it is in fact undesirable to indicate the number of CLI digits as this can result in the 'end of CLI' signal appearing in the DDI field, so omission of the -cCnn value will leave the protocol to default it to a large value. If I-15 is not provided (and this is rare), then use of -cCnn may be necessary. It sometimes seems necessary however to use the -cDnn switch to establish a fixed number of DDI digits, particularly if CLI is also being requested, as some Central Office switches seem to regard a pulsed 'CLI request' signal (necessary when the exact number of DDI digits is unknown) as illegal. In this case it may be possible to use the configuration switch that automatically requests the CLI in the middle of receiving the DDI digits, (although this may not be possible on all switches). This has the desirable side-effect of allowing variable length DDIs. 8 Release of Incoming Calls before Answer It should be noted that under almost all of the R2 line signal- ling specifications encountered, incoming calls cannot normally be rejected or cleared via line signalling before answer, and this is the default provision of the implementation. However, it is believed that some exchanges might allow this and consider it to be legal line signalling, so this has been introduced as a driver option, as below. Typically, if this is not regarded as legal line signalling, the exchange may well take the channel temporarily out of service, and if this occurs, this option should not be used. Early release of incoming calls via line signalling is controlled by configuration switch -s0. See the section below on control of group-B signal control for further information. 9 Control of Group-B Signals (Incoming Calls) The Group B signal is a signal sent from the incoming (called) end back to the outgoing (calling) end at the completion of the compelled signalling sequence, to indicate the state of the called extension (number). It can indicate that the called number is not available because for a variety of reasons (Busy, out of order, unobtainable etc) and as such will not be answered, and it can also indicate that the called number is available, and that (if answered) it will be answered with or without charging (or certain other conditions). For incoming calls, if the incoming call is rejected at the API by the use of a default clearing cause or a specific cause, via call_disconnect() or call_release(), the clearing cause provided to the API will now be mapped to a specific group-B signal (see the table at the end of this document) which will immediately be sent to the outgoing end. The incoming end will then enter a state where the call may not subsequently be answered, but is awaiting forward clearing from the outgoing end (which should be forthcoming). Note that call_disconnect() or call_release() MUST be used prior to (and without using) call_incoming ringing(), otherwise a default acceptance code will be sent, and no rejec- tion or clearing will be possible until after answer. If an incoming call appears without a call_openin() having been made (ie. not 'open for incoming'), a default group B signal will be returned to the outgoing end indicating that the channel is busy. For incoming calls, if the application wishes to use an accep- tance code other than the default (line free, normal charging), it is able to send one of five answer codes to the API via a new API function call_answercode() (which must be called PRIOR to call_accept() or call_incoming_ringing()), which will subsequent- ly be mapped to a group B signal sent as a result of call_incom- ing_ringing() or call_accept(). Call_answercode() takes a cause parameter identical to call_disconnect(), but with new enumerated values. Three of these are standardised, and there are two spares which may be mapped to any additional group B signals which might be implemen- ted under specific R2 variants. Standard cause values which are not available under a specific variant will be mapped to the default cause. If call_answercode() is not called, the default group B signal of B-6, or that supplied via -s8 will be used instead. The standard causes are:- AC_CHARGE line free (charging) (default) AC_NO_CHARGE line free (no charging) AC_LAST_RELEASE called party or last party release (used for malicious call tracing) AC_SPARE1 alternate possible code AC_SPARE2 alternate possible code To summarise, on incoming calls, the group B signal is only sent as a result of either:- i) call_disconnect() or call_release() ii) call_accept() or call_incoming_ringing() iii) incoming call without a call_openin() IMPORTANT These group B signals will only be sent if switch -s1 is used. 10 Control of Group-B Signals (Outgoing Calls) For outgoing calls, if the call is rejected at the incoming (called) end, the card will receive a group B signal, which will be mapped to standard API clearing causes (see the table at the end of this document) which may be recovered by the use of the call_getcause() API function. If the call is accepted at the incoming (called) end, the group B signal received by the card is mapped to a standardised API acceptance cause (a new API feature introduced specifically for MFC R2 support), which can also be recovered by the call_get- cause() function (not previously available under the API). 11 Mapping of Group-B to API Causes In every case (the default case, and in the case of specific national implementations controlled by the -s12 switch) there will be default mappings between group B signals and incoming and outgoing acceptance and rejection causes. In every case, the supplied default or national mapping may be overridden by supply- ing certain -s switches, as follows:- Switches -s60 to -s74 override the mapping, on outgoing calls, of incoming group B signals to answer (AC_) and release (LC_) codes. Switches -s75 to -s79, on incoming calls, map supplied accept_codes (AC_) to group B signals sent to indicate that the called number is free, and might be answered. Switches -s80 to -s95, on incoming calls, map supplied clearing causes (LC_) to group B signals that indicate that the call will never be answered, and should be released by the outgoing end. It should be noted that, as there is not an exact 1:1 relation- ship between API causes and group B signals, some loss of meaning in the mappings will result. In particular, two cards back-to- back will map an LC_ code to group B signal, then back to an LC_ code:- eg. in the default mapping, LC_NUMBER_CHANGED will map to signal B-5 (unobtainable) which will map back to LC_NUMBER_UNOB- TAINABLE. Thus the exact meaning has been lost, but the general sense of the cause has been retained. 12 API Handling of Incoming Calls With R2T1 This diagram shows the typical dialogue between application and device driver when waiting for an incoming call. Application | Library/Device Driver /-------------------------\ | /-------------------------\ -->| call_openin (indetails) | ----->| Initiate Incoming Call | | \-------------------------/ | | Return handle | | /-------------------------\<------| | | | | \-------------------------/ | | call_event ( state ) | /-------------------------\ | | | ----->| Wait for event to occur | | \-------------------------/ | Return handle and state | | ^ \-------------------------/ | | /------------------------------\ | | |______| EV_WAIT_FOR_INCOMING |______| | | \------------------------------/ | | | /------------------------------\ | | | | EV_INCOMING_CALL_DET | | | | | EV_DETAILS | | | | | | | | | | call_details(details) | | | | | if ( enough ddi digits ) | | | |------| if ( ddi_OK & NO_CLI ) |------| | | | call_incoming_ringing| | | | | call_accept | | | | | else if ( ddi_OK & CLI) | | | | | call_get_orig_addr | | | | | call_answercode | | | | | call_incoming_ringing| | | | | call_accept | | | | | else | | | | | call_disconnect | | | | \------------------------------/ | | | /------------------------------\ | | | | EV_CALL_CONNECTED | | | |______| application |______| | \------------------------------/ | | /------------------------------\ | | | EV_IDLE | | |____________| call_release(cause) |______| \------------------------------/ The application issues a call_openin function to the device driver. The driver initiates the wait for incoming call and returns control to the application with the call handle. The application is now free to issue new commands to the device driver. To ascertain the progress of a call the application may use the call_event function. The device driver will return the state of the call and a call handle on which the event occurred. The arrival of an incoming call is signalled by the event EV_INCOMING_CALL_DET, whereupon the application may use the call_details function to obtain information about the incoming call, in particular any DDI information in the destination_addr field of the details_parms. Unlike ISDN signalling systems, the DDI information will never arrive en-bloc (all at one time) but will always arrive as over- lap receiving (one digit at a time). If the whole number was available at the outgoing register at the time that the call was forwarded, the digits will arrive quite fast, possibly around 100mS per digit. It is equally possible that the digits will arrive at the rate they were dialled by the caller - ie. quite slowly, and this should be taken into account. In addition, it is quite possible for a caller to dial insuffi- cient digits to complete the DDI. However, as noted before, it is not usually possible to backwards release an incoming call before it is answered, so the application may either disconnect the call at the API, in which case the channel will not go IDLE until the caller goes ON-HOOK, or it may simply wait until the caller goes ON-HOOK, and the channel goes to IDLE, then release the call. Additionally, it should be noted that, unlike ISDN signalling systems, it is not the case that CLI information will be present at this stage, as it must be explicitly requested. To obtain the CLI the application must invoke the call_get_originating_addr function, which actually requests the CLI from the exchange. As each CLI digit becomes available for the application, further EV_DETAILS events will be issued. If the call is to be accepted, an group-B acceptance cause may be provided using call_answercode(). When the application is satisfied that it has received all avail- able details, the function call_incoming_ringing may (optionally) be used, then, after the card has completed the necessary com- pelled tone signalling sequence, the application will receive the EV_WAIT_FOR_ACCEPT event, and a ring tone cadence may be sent to the caller over the B-channel. It is not absolutely necessary to go through this stage, as the application may answer immedia- tely, in which case no RING TONE will be heard by the caller, and no EV_WAIT_FOR_ACCEPT will occur. The exact purpose of the EV_WAIT_FOR_ACCEPT is to allow the application program to know when the compelled sequence has been completed, so that the B-channel may be switched to some other (custom) ring tone generator source without danger of cutting off some of the tone signalling. It is useful to know that the default ring cadence starts off with a cycle of silence, to avoid a partial cycle in the event that the application is a little slow in 'getting there' in switching to the external ring gener- ator. Two alternate ring cadences are available, the default being a 425Hz tone, 1 second on and 3 seconds off, and the alternate being 0.4S on, 0.2S off, 0.4S on, then 3S off. The default is to produce no ring cadence at all, but the EV_WAIT_FOR_ACCEPT is still generated. Any time after the EV_WAIT_FOR_ACCEPT (perhaps a short delay to allow a few cycles of ringing) the application may use call_accept to accept the incoming call, whereupon the driver connects the call and the EV_CALL_CONNECTED event will be gener- ated. When the call is released from the near end, the driver discon- nects the call and after the far end has released the call the EV_IDLE event will be emitted. If the call has been released at the far end, the EV_IDLE event will be emitted immediately. As always, before the channel can be used again after the EV_IDLE state is received, the application must release the handle (call_release), then subsequently (very promptly) idle the time- slots by using the call idle_net_ts, which also reconnects the DSP to the B-channel ready for the next cycle of compelled tone signalling. It is possible on incoming calls to periodically call the call_put_charge function, each of which will transmit a meter pulse to the far end. This is not recommended (!) for use on exchange lines, as the exchange will not be expecting it, and may take the line out of service, and in any event there would prob- ably be difficulty in persuading the PTT to pay the bill!. This feature is actually only provided for test purposes, and those installations where the card is emulating an exchange line. 13 API Handling of Outgoing Calls With R2T1 On outgoing calls, prior to dialling, the card makes no attempt to detect the presence of DIAL TONE as it is rarely available on MFC R2 due to the fact that the B-channel is used for in-band tone signalling. Instead, the card relies on the SEIZE ACKNOW- LEDGE line signalling, and the compelled nature of MFC R2 should deal with any other issues. If it is required that DIAL TONE should be detected by an exter- nal speech processing card prior to dialling, if no destination address is supplied on call_openout, the speech card can be used to detect the DIAL tone, then the entire destination address may be supplied in one go, using call_send_overlap. Care must be taken that the bidirectional connection between the port and the DSP is not disturbed during this operation. The event EV_OUTGOING_RINGING will be encountered when (and if) the compelled signalling indicates that the called subscriber's line is free, and speech conditions have been set up to the far end. EV_OUTGOING_RINGING does NOT indicate that the card has actually detected RING TONE in-band, as this is not attempted due to the possible wide variation of ringing frequencies and cadences that may be encountered. It's purpose is to indicate that dialling is complete, and the call has either arrived at a free subscriber which is not ringing, or in-band call progress tones are signal- ling a call failure cause, for example, BUSY, UNOBTAINABLE, NUMBER NOT IN USE or OUT OF ORDER. Thus if actual RING TONE or CALL PROGRESS tone detection is required, an external speech processing card could be used after EV_OUTGOING_RINGING for this purpose. After EV_OUTGOING_RINGING has been received, and after EV_CALL_CONNECTED has been received, a call acceptance value may be recovered from the API, via call_getcause. Alternatively, if the call is rejected at the incoming (called) end, if remote disconnect is not used (no CNF_REM_DISC), EV_IDLE will be received, and a clearing cause may be recovered via call_getcause. If remote disconnect is used, EV_REMOTE_DISCON- NECT will be received, a clearing cause will be available via call_getcause, and the call should be released in the usual manner (described below). During the call, if the CNF_CALL_CHARGE option has been set, the API will return EV_CALL_CHARGE events, which may be counted by the application. In addition, the device driver itself counts received meter pulses, and this count can be recovered from the API by the use of the call_get_charge function. For both incoming and outgoing calls, if the call is released from the far end, and the 'remote disconnect' feature of the release 3 device drivers is enabled, the API will return EV_REMOTE_DISCONNECT, but the signalling system will not actually release the channel at the near end until either call_disconnect or call_release is called, but bear in mind that outgoing calls will usually continue to be charged until disconnected or re- leased. Also, if the call is not released at the near end, it is often possible for the caller to go off-hook again, and re-an- swer!. 14 'Clearback' Feature Some networks, and Brazil is known to be one of them, use a feature that is sometimes called 'clearback' on answer, or 'do- uble answer'. In this, a short time after answer the card must output a 'clearback' signal for a short period of time, then return to answer. This is used to reject calls from payphones, and collect calls. An -s switch is provided to enable this feature, and another switch is provided to control the length of the clearback condition. Note that the EV_CALL_CONNECTED event is not returned until after the clearback pulse has finished. In such a network, outgoing calls may also experience this effect upon far-end answer, whereby, if 'remote disconnect' is enabled the EV_REMOTE_DISCONNECT will be seen immediately after answer, but the call will otherwise appear proceed fairly normally. If it is not enabled, the line will appear to clear immediately after answer. Current versions of the CAS driver leave the line state at EV_REMOTE_DISCONNECT, but later versions will return to EV_CALL_CONNECTED after the clearback pulse ends, so that the sequence will be CONNECTED, REMOTE_DISCONNECT, CONNECTED. Is is not possible to defer the CONNECTED event until the second in- stance, as the protocol has no way of knowing that this is actu- ally going to happen. A way of overcoming the REMOTE_DISCONNECT state is to set -s26 to a long period, perhaps 2.5 seconds (- s26,250), then the clearback pulse will be considered to be a meter pulse, and an EV_CALL_CHARGE event will be returned straight after call_accept(). Alternatively, the application may wish to recognised the presence of the clearback signal at the far end, and prevent connection to such a service by releasing the call immediately (perhaps to prevent premium rate services to be accessed). 15 Configuration Switch Settings for R2T1 This sections details the CONFIG.SYS switch settings (and confi- guration string switches for UNIX), for various optional features in R2T1. The use of these switches within CONFIG.SYS will be similar to the following:- device = c:\sys\mvclcas.sys -p380 -i10 -s1 -s3,9 -s8,6 See the device driver release notes and README files on disk for full information on device driver installation and the normal switches (-p, -i, -d etc). Note that -s switches may also be used with a network port num- ber, as in -s8,1N0. Switches shown below marked with '*' are optional, but recommen- ded for use where possible. -s0 allows backward release of incoming calls - this is normally considered illegal and so should probably not be used. -s1 * on incoming calls, causes request of group II/group B signals on completion of tone signalling. These are not currently made available through the driver, al- though, as there is some call progress information available via this method, this functionality is inten- ded at some future date. This switch can usually be used freely, and is in fact often mandatory. Note that the use of call progress (group B) signals depends upon the use of this switch. -s2,x on incoming calls, causes a single (-s2,1) or dual (- s2,2) ring back cadence to be generated as a result of call_incoming_ringing(). Each cadence is 425Hz, single ring is 1 second on, 3 seconds off. Dual ring is 0.4S on, 0.2S off, 0.4S on, 3 seconds off. This switch can be used freely, but ring tone cadences may be subject to local regulation. -s3,x if CLI/ANI is requested, causes signal A-x rather than A-5 (the default) to be generated and recognised as CLI request. The use of particular signals as CLI request is implementation dependent hence this switch should be used with care. If this switch is used, then (unless determined otherwise by setting -s12,x national switches) A-5 sends only the caller category, and not CLI. -s4 * on incoming calls, strips off the 1st digit (caller category digit) from the returned CLI value (for the sake of compatibility with the API for other signalling systems), otherwise the category digit is returned preceding the first CLI digit. This switch can be used freely, as it only modifies the presentation of infor- mation via the API. -s5,x Caller category (Group II) signal control for outgoing calls. Without setting this switch, the default is to send the caller category before CLI, and to use the default value of II-1, or as set by -s7. -s5,1 Do not prefix CLI with the caller category, but caller category is as set by -s7. -s5,2 Prefix CLI with the caller category, and the caller category is provided by the first CLI digit. -s5,3 Do not prefix CLI with caller category, but caller category is set by the first CLI digit, hence on CLI request send CLI starting at the second digit. -s6 on outgoing calls, upon requests for CLI with no CLI digits available at the API, responds with an I-15 (end of CLI) rather than an I-12 (request not accepted). -s7,x on outgoing calls, sets the value used for the group 2 signal to (x), rather than II-1 (the default). This is national implementation dependent. This value is ignored if -s5 is set to take the caller category from the CLI field, unless the CLI field is empty. -s8,x On incoming calls, sets the group B free subscriber signal to (x), the default if this switch is not expli- citly used is -s8,6. -s9 Modifies the line signalling to change only one bit at a time. This only influences the response to forward clearing by clearing back via the back-busy state in the same way as normal backwards clearing. -s10 Causes I-15 to be accepted as an 'End Of Pulsing' signal for DDI address on incoming calls, and prevents the 'F' that would otherwise be generated from being appended to the incoming destination address field. -s11 Inhibits the generation of either the I-12 or I-15 signal as 'end of CLI'. Receiving CLI relies upon the -cCnn CLI count to determine the number of CLI digits. -s12,2 Produces China #1 R2 line signalling and register signal meanings, and hence always uses Group B signals (turns on -s1), sets the appropriate CLI request parameters (-s3,6, -s6 and s13,1), and sets modified line signalling (s9). The caller's category is left to default to II-1 (-s7,1) but the default free subscriber answer signal must be explicitly set to B-1 (-s8,1). -s12,3 Produces Brazil 5C MFC R2 signal meanings, and hence always uses Group B signals (turns on -s1), and sets the CLI request signal to A-5 (sets -s3,5). The call- er's category is left to default to II-1 (-s7,1 which should be correct) and the default free subscriber answering should be set to B-1 (-s8,1). -s12,4 Produces Mexican R2. Always uses group B (-s1), sets CLI request to A-6 (-s3,6), subsequent CLI requests to A-1 (-s13,1), no CLI to I-15 (-s6). -s12,5 Produces Columbian R2. Always uses group B (-s1), sets CLI request to A-6 (-s3,6), subsequent CLI requests to A-1 (-s13,1), with modified line signalling (-s9). -s12,6 Produces Australian P2 (AKA TS003 and R2D). Always uses group B (-s1), no CLI possible. -s12,7 Produces Indonesian SMFC R2 (semi-compelled R2). Always uses group B, sets CLI request to A-6, (-s3,6), backwards signals to 150mS fixed period (unless mod- ified by -s27). -s12,8 Produces Croatian MFC R2 register signalling, and always uses group B for MFC. (See notes at end of document regarding other switches). -s13,x Sets a different value for CLI digit request signals subsequent to the first CLI request signal. The de- fault is that all CLI request signals are the same as the default (or the value set using S3). -s14,x On incoming calls, causes the CLI to be automatically requested after receiving x DDI digits. If this option is not selected (which is the default) then CLI needs to be explicitly requested using call_get_origin- ating_address. If selected, that function is not required and the CLI will be available using call_details before x+1 DDI digits are received. Note that it is not known whether this procedure is valid in all R2s, but it was introduced to overcome a problem found on at least one exchange using China No1, whereby pulse reception of the CLI request (required when having received fewer DDI digits than the number set using -cDnn in the CONFIG.SYS device= line) caused the call to be released. Using -s14,1 causes the CLI to be automatically fetched after the first DDI digit, com- pletely overcoming the problem. -s15,x * During receipt of CLI, prevents recognition of ring and answer commands prior to receipt of the 'end of CLI' signal (usually I-15). If this switch is used to inhibit commands, the 'call_incoming_ringing' or 'call_accept' API call may be any time after the first CLI digit has been received. If this switch is not used to inhibit commands, care must be taken to ensure that the entire CLI has been received, plus either a timeout to allow the 'end of cli' signal to arrive or inclusion of the 'C' or 'F' option along with recognition of same, before issuing these API calls (as this may terminate the compelled signalling prior to receiving 'end of CLI', which some central offices will consider illegal). Thus the use of this switch is recommended if an 'end of CLI' signal is provided. However, with no 'end of CLI' signal and in the event of insufficient CLI di- gits, it will prove impossible to cause ring or answer, as the API commands will be deliberately ignored. -s15,0 (the default) does not inhibit ring or answer, and does not show 'C' or 'F'. -s15,1 shows the I-12 signal as 'C', and I-15 as 'F' at the end of the CLI address, but does not inhibit ring or answer. -s15,2 inhibits ring and answer during CLI collection, without showing 'C' or 'F'. -s15,3 shows 'C' and 'F', and inhibits ring and answer. -s16 Causes production of a 425Hz 'dialtone' on incoming calls, immediately upon seizing, which disappears upon detecting the first dialled digit. This may not be very useful, and may in fact upset some central office switches. -s17 Allows receipt of register signalling via decadic (pulse) dialling on the A bit. As there is reduced information transfer when using decadic, all of the call progress and caller category information is ab- sent, and CLI is not available. If this switch is set, any pulse on the A bit after seize will cause the protocol to ignore tone signalling, so only set this switch if decadic reception is really required. -s18 Forces outgoing calls to use decadic (pulse) dialling on the A bit. As there is reduced information transfer when using decadic, all of the call progress and caller category information is absent, and CLI is not avail- able. -s19 Forces alternate meter pulse type. Currently, use of this switch causes the call_put_charge() API call to generate a 'hookflash' instead of a charging pulse. This is an interim measure to generate a hookflash, prior to 'doing it properly'. Note that, because of its origin, it is currently only possible to use this on incoming calls. -s20,x Sets time supervision while transmitting forward signals to x seconds. On timeout, will clear forward. Default is no time supervision. -s21,x Sets time supervision while transmitting forward no tone signals to x seconds. On timeout, will clear forward. Default is no time supervision. -s22,x Sets time supervision while receiving forward signals to x seconds. On timeout, will generate a pulsed A-4 (or B-4) congestion signal (or as set by -s30), which should result in the outgoing end clearing forwards. Default is no time supervision. -s25,x Sets length of meter pulse to x*10mS (default 150mS). -s26,x Sets the maximum period of time considered to be a meter pulse (prior to being regarded as clearing) to x*10 mS (default 350mS). -s27,x Enables semi-compelled signalling; ie. sets backwards signals to fixed x*10mS periods, a value frequently used is 150mS (-s27,15) (with the switch not set, the default is fully compelled signalling). -s28,x Causes outgoing register signalling to be DTMF rather than MFC. As there is reduced information transfer when using DTMF, all of the call progress and caller category information is absent, and CLI is not avail- able. The mark/space ratio of the DTMF tones is fixed at 1:1, with tone duration fixed at x*10mS, a value frequently used is 80mS (-s28,8) (with the switch not set, the default is MFC R2). -s29 Causes incoming register signalling to be assumed to be DTMF rather than MFC. As there is reduced information transfer when using DTMF, all of the call progress and caller category information is absent, and CLI is not available. (Default is MFC R2). -s30 Overrides the default value for the A or B backwards pulsed 'congestion' signal sent as a result of expiry of the time supervision of receiving forward signals. (Default is A-4 or B-4). -s32 Allows any signal to register as a digit in the CLI field, except signal 15 (which is universally used as end of CLI). Specifically, this allows reception and acceptance of any group II signal preceding the CLI (even such as II-12, which would appear as 'C'), without preventing the acceptance of the following CLI itself. -s33,x Modifies the use of answer supervision line signalling for Croatian R2 (and may be applicable elsewhere) whereby upon recognition of seize, the incoming side goes immediately to conversational state. The various values shown below may be added together to produce an aggregate effect. x=1 Modifies outgoing line signalling on incoming calls, by going directly to answer upon seize. x=2 Copes with modified incoming line signalling on outgoing calls when the line signalling goes directly to answer. x=16 On incoming calls with modified outgoing line signalling, automatically produces a single meter pulse upon call_accept(), which may be interpreted by the far end as indicating that the call has been an- swered. x=32 On outgoing calls with modified signalling, causes return of EV_CALL_CONNECTED when a meter pulse has been seen. If outdialling with pulse or DTMF, it is recom- mended to use this switch even if metering is not ap- plied, as it allows clearback to be identified. For pulse or DTMF, if a meter pulse on answer is NOT re- ceived, it may be appropriate to use the -s34,x flag to cause a move to the connected state after a timeout, otherwise the driver will never move to connected. With modified signalling, and this switch is not set when outdialling with MFC, the driver will move to connected immediately at the end of the compelled signalling. -s34,x On outgoing calls, causes the protocol to indicate movement to the connected state x * 100mS after the last digit has been sent. Useful for use with DTMF or pulse outdialling in the presence of modified line signalling such as described for -s33. -s35,x On incoming calls, this switch enables the 'clearback' feature, which in some networks will reject collect calls, and calls from payphones. If this switch is used, after call_accept() the answer line signalling will be sent for x*100mS, then the clearback signal for 2 seconds (or as set by -s36), then answer signal again. A typical value would be 1 second (x = 10); -s36,x If -s35 is set, then this switch overrides the default two second disconnect period with a value of x*100mS. -s60 to -s74 These switch locations provide overrides to the mapping for outgoing calls, between the received Group B sig- nals and the answer or clearing cause returned via the API. Switch -s60 sets the returned value for B-1, -s61 the value for B-2, up to -s74 setting the returned value for B-15. If these switches are left unset, the default returned mapping will be as in the table below. Note that certain national switch settings (the -s12 switch) will modify this default mapping, but that it may still be overridden here. To set a B-signal to return a clearing cause (LC_xxx) value, set the switch to the enumerated value of the relevant LC_xxx code. To set a B-signal to return an answer code, set it to the value of the answer code plus 16. Thus to alter the mapping to return answer code 2 from B-6, set -s65,18. These switches may usually be left untouched as their default values should be very suitable (default mappings are shown after the colon ':'). -s60 (B-1 free, last party release) : 19 ANS_CODE_3 -s61 (B-2 intercepted) : 6 LC_INCOMING_CALLS_BARRED -s62 (B-3 busy) : 1 LC_NUMBER_BUSY -s63 (B-4 congested) : 8 LC_CALL_FAILED -s64 (B-5 unobtainable) : 3 LC_NUMBER_UNOBTAINABLE -s65 (B-6 free, charge) : 17 ANS_CODE_1 -s66 (B-7 free no charge): 18 ANS_CODE_2 -s67 (B-8 out of order) : 5 LC_OUT_OF_ORDER -s68 (B-9 spare) : 1 LC_NUMBER_BUSY " " " " " -s74 (B-15 spare) : 1 LC_NUMBER_BUSY -s75 to -s79 These switches provide overrides to the mappings between the five available API answer codes and out- going Group B signals for incoming calls. The default settings are as below shown after the colon:- -s75 ANS_CODE_1 : B-6 (free, charge) -s76 ANS_CODE_2 : B-7 (free, no charge) -s77 ANS_CODE_3 : B-1 (free, last party release) -s78 ANS_CODE_4 : B-6 (free, charge) -s79 ANS_CODE_5 : B-6 (free, charge) -s80 to -s95 These switches provide overrides to the mappings between clearing causes and Group B signals for incoming calls. Note that it is only possible to send or receive a clearing cause if clearing occurs before RINGING or ANSWER, clearing after ANSWER will result in a cause of LC_NORMAL (enumerated as 0, and hence impossible to set via -s60 to -s74). The default settings are as below shown after the colon:- -s80 LC_NORMAL : B-3 (busy) -s81 LC_NUMBER_BUSY : B-3 (busy) -s82 LC_NO_ANSWER : B-3 (busy) -s83 LC_NUMBER_UNOBTAINABLE : B-5 (unobtainable) -s84 LC_NUMBER_CHANGED : B-5 (unobtainable) -s85 LC_OUT_OF_ORDER : B-8 (out of order) -s86 LC_INCOMING_CALLS_BARRED : B-2 (intercepted) -s87 LC_CALL_REJECTED : B-5 (unobtainable) -s88 LC_CALL_FAILED : B-4 (congested) -s89 LC_CHANNEL_BUSY : B-3 (busy) -s90 LC_NO_CHANNELS : B-3 (busy) -s91 spare : B-3 (busy) " " : " " -s95 spare : B-3 (busy) -s98 Informs the software on the card that no DSP is fitted, allowing the use of both line signalling and decadic (pulse) register signalling without suffering from problems due to absence of DSP hardware. Setting this switch automatically enables generation and reception of decadic register signalling, equivalent to setting -s17 and -s18. -s99,n Enables protocol trace generation by the software on the card. If n=1..31 the generated trace is enabled for channel n (as long as n != 16), if n=32 then trace is enabled for all channels (except 16). The left bit trace and tone columns are the transmitted signals, and the right bit trace and tone columns are the received signals. The characters 'f' and 'b' stand for 'forward' and 'backward'. Only use this facility for debugging - do not leave it enabled in production systems (unless absolutely neces- sary) as it does affect the performance of the proto- col. 16 Summary of Default Signals (With No switches set) Default 'Send next digit' (n+1):- A-1 Default 'Send last but 1 digit' (n-1):- A-2 Default 'Go to Group B':- A-3 Default 'Congestion':- A-4 Default 'Send Caller Category' & 'CLI request':- A-5 Default 'Go to Speech':- A-6 Default 'Send Last but 2 digit' (n-2):- A-7 Default 'Send last but 3 digit' (n-3):- A-8 Default 'No CLI' or 'Not Accepted':- I-12 Default End of CLI signal:- I-15 CLI is not automatically requested Default Group II (Caller category) signal:- II-1 Default Group B (Line free, charge) signal:- B-6 Default ring back:- none Default dial tone:- none Note that most switches produce fairly small modifications to the signals and signalling, whereas the -s12 switches produce multi- ple and more fundamental changes to the signalling set, including 'Send last but N' (changes which are not documented here.) 17 Switches for National R2 Implementations This section details switch settings that are known to be re- quired in certain national R2 implementations. Some of the other switches may be used with caution, provided the implications are fully understood. Blue Book R2, A-5 CLI -s1 Blue Book R2, A-9 CLI -s1 -s3,9 -s5,1 Portugal MFC R2 -s1 Norway National MFC R2 -s7,2 -s20,21 -s21,27 -s22,24 (in some cases, Norway requires outgoing calls to use DTMF, in which case use -s28,8 on the User end, and -s29 on the Network end) Israel MFC R2 -s1 -s3,9 China #1 MFC R2 -s12,2 -s8,1 (-s14,1 recommended if using CLI) South Africa MFC R2 -s10 Malaysia -s1 -s3,6 -s7,2 -s8,1 -s10 Mexico -s12,4 -s7,2 -s8,1 Peru MFC R2 -s3,9 Brazil 5C MFC R2 -s12,3 -s8,1 Columbian R2 -s12,5 -s7,2 -s8,1 Chile -s1 -s10 Australian R2D -s12,6 -s7,2 -s8,1 Indonesian SMFC R2 -s12,7 -s7,2 -s8,1 Thailand -s1 -s7,2 -s8,1 -s28,8 (DTMF is used for outgoing calls. Substituting -s29 for the -s28,8 will emulate the Network end) Belgium -s1 -s3,5 -s5,7 -s8,1 -s13,9 The approved software for customer access in Belgium is a different file called M1BELGU, and uses DTMF for outgoing calls (as is required for normal customer access lines in Belgium). However, within the network both way MFC is used, and as a result R2T1 may be used and configured as above. Also, similar results to the approved version (M1BELGU) may be obtained using the switches as above, but with the addition of -s28,8 at the User end to force the generation of DTMF on outgoing calls. To use R2T1 as a network end for M1BELGU for development purposes or otherwise (previously a software called M1BELGN was supplied, but R2T1 is now a much better solution), requires generation of dialtone (-s16), and requires recog- nition of DTMF rather than MFC (-s29), so use:- -s1 -s3,9 -s5,7 -s8,1 -s16 -s29 Croatian R2 -s12,8 -s28,8 -s33,34 The specifications in hand for Croatian line signalling indicate that incoming calls are fairly standard MFC, but that a modified line signalling is used for calls towards the public network (so -s33,34), and that outgoing calls may use either DTMF or pulse dialling, but NOT MFC, (thus -s28,8 for 80mS DTMF, OR use -s18 for decadic pulse dialling). The -s34,34 causes modified line signalling on outgoing calls, but also interprets an incoming meter pulse as the call having been answered. If no meter pulses are returned, it may be useful to use (say) -s34,50 to return EV_CALL_CONNEC- TED 5 seconds after the last digit sent, but the application may need to monitor for in-band speech to really deal with things properly. To emulate the C.O. (central office) use:- -s12,8 -s29 -s17 -s33,17 18 Auto Back-Busy Option Switch The device driver auto back-busy option is available on the R2T1 firmware and the associated CAS driver software, whereby channels not 'open_for_incoming' will automatically present back-busy. Examples for the auto back-busy switch are as follows:- -cBBY global back-busy, affects both ports -cBBYn0 global back-busy, affects port 0 -cBBYn1 global back-busy, affects port 1 -cBBY,FF0000FF selective back-busy, affects both ports (timeslots 1..7 & 24..31) -cBBY,0000FFFFn0 selective back-busy, affects port 0 (timeslots 1..15) -cBBY,FFFF0000n1 selective back-busy, affects port 1 (timeslots 17..31) The value after the comma is a hexadecimal LONG INTEGER. The least significant (rightmost) bit represents timeslot 0, and the most significant bit (leftmost) bit represents timeslot 31, however, as there is no Bearer Channel for timeslots 0 or 16, the bits for those positions have no effect, and are ignored. * * *