E1 R1/E&M CAS Protocol V1.2 Release Note & Implementation Guide : 13-07-95 Aculab 1 Introduction and Scope This release note considers the use of the Aculab ISDN/E1 card with the CAS E&M Signalling System 'R1EM', and the implications 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 dri- vers, and are not available with any previous release, and indeed this signalling protocol is not supported by any device driver prior to Release 3. This firmware implements several versions of E&M line signalling with R1 register signalling, and may be used in the reception of signalling that perhaps originated in a T1 network, and has been (partly) converted to E1, but which retains it's original R1 register signalling. The variants of line signalling implemented by this firmware are E&M 'immediate start', E&M 'delay dial', and E&M 'wink start. The E&M signalling protocol is a 1-bit protocol (although 2 bits are used, the B bit following the A bit), and so is somewhat sparse in features, and depends somewhat upon timing. The imple- mentation described here uses DTMF for register signalling. Note that, by way of illustration, this document uses the EV_xxx (event) scheme provided by the API to describe various telephony issues, but the state based approach is equally valid. 2 Basic Functionality Outgoing Line seize, with recognition of either delay dial or wink start. Call Setup, with Destination Address (DTMF) Explicit of automatic generation of KP and ST Overlap Sending (DTMF) Recognition of Charging Pulses (optional) Call Release Remote Disconnect on Release (optional) Incoming Recognition of seize, optional wink generation Generation of dial tone (optional) Call Accept, with DDI digits (DTMF) Generation of two alternate Ring Tones (optional) Generation of Charging Pulses (optional) Call Release 3 A Caution As with all signalling systems that us tone-based register sig- nalling, the digits can only be generated or received if the tone generators or receivers are connected to the B channel whilst the tones are present. The same goes for call progress signals, such as dial tone or ring-back. On the Aculab E1 card, tone signalling is provided by a DSP module attached to the main E1 card. The API library call 'system_init()' connects the trunk (all B channels) through to the DSP module (when present) on the E1 card prior to the first call, and if the library function 'idle_net_ts()' is used at the end of every call, it will recon- nect the channel to the DSP module ready for the next call. Typically, the programmer should ensure that outgoing B-channel connections are not made from either the PEB or MVIP bus until the call has answered, or at earliest after all outgoing signal- ling (or call progress tones if required on incoming calls) have completed. The incoming B-channel may be connected through to resource cards at any time, as this will not disrupt the connection to the DSP module (the switch matrix can make a 'one-to-many' connection, but not a 'many-to-one' connection - only the last connection made to a certain point is effective). 4 Driver Configuration For Aculab's generic CAS and R2 device drivers, it is sometimes useful (and occasionally vital) for the device driver and signal- ling system firmware to known the number of DDI and CLI digits supported by the trunk via the -cDn and -cCn driver configuration switches. For this signalling system it is NOT necessary to tell the driver how many DDI digits to expect, and indeed CLI is not supported at all. It should be noted that in common with many CAS and R2 protocols, incoming calls cannot be rejected or cleared before answer in the way that ISDN allows, and this is true of this implementation. As early release or rejection is not available, a call could be incoming even prior to the application issuing a 'call_openin()', (unless arrangements have been made for automatic back-busy) and if present, such a call will be recognised and made available via the API when the application requests an event with 'call_event()'. However, a caller attempting to call in to the system without a call_openin having been made, will normally just hear silence. 5 Implementation Details This signalling system is balanced, meaning that the same proto- col may be used at both ends of a link, for both-way working (although of course, only one end - usually the network or Cen- tral Office end - should be sourcing the clock for the link). 6 Incoming Calls On incoming calls, the implementation will not produce the 'delay dial' signal unless it has been specifically configured to pro- duce a 'wink' (which is indistinguishable from a delay dial and PTS signal). In addition, if no dialled digit is received within 10 seconds, the line will be regarded as 'back-busied'. It is expected that any incoing dialled string will start with KP and be terminated with ST, and there is an '-s' switch that will allow these to be shown as 'K' and 'S' in the incoming DDI field if required. Unlike ISDN signalling systems, the incoming destination address or DDI digits will never arrive en-bloc (all at one time) but will always arrive as overlap 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 125mS 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 incorrect digits, or insufficient digits to complete the DDI. However, as noted before, it is not possible to backwards release an incoming call before it is answered, so the application may either discon- nect 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. An alternative would be to play BUSY or NU tone to the caller, to persuade him to drop the call (there may or may not be a backward path through the Central Office network that will allow the caller to hear these tones). On incoming calls, if the application sends 'call_incoming_ring- ing()' the implementation will wait for the ST signal (if not already received) then optionally generate one of two ring tone cadences whilst waiting for answer, and the API will return the event EV_WAIT_FOR_ACCEPT. The exact purpose of the EV_WAIT_FOR_ACCEPT is to allow the application program to know when in-band register signalling has been completed, so that the B-channel may be switched to some other (custom) call progress tone generator source without danger of preempting some of the signalling. If 'call_incoming_ringing()' is not used, then no ring back, and no EV_WAIT_FOR_ACCEPT will be generated. Once connected, the incoming end can generate backwards meter pulses, nominally 150mS wide, via 'call_put_charge()', although some implementations may not allow these, and they may cause clearing at the outgoing end. Also, they may be quite indis- tinguishable from a 'hookflash' or 'recall' signal, if these are implemented. When incoming release is recognised, if the 'remote disconnect' feature is used by the application, the incoming end will not return clearing until 'call_disconnect()' or 'call_release()' is called by the application. It may be useful for the programmer to know that timeslot 0 of the DSP output stream (stream 17 for port 0 or stream 19 for port 1) is initialised to produce a signal of 440Hz at -8dBm0, which may be switched on and off (using 'set_output()' with mode=PAT- TERN_MODE and pattern=0x54, silence) to any (possibly multiple) B channels to produce other call progress tones, via an appropriate cadence. 7 Outgoing Calls On outgoing calls, the implementation will make no attempt to detect the presence of dial tone, but instead relies of the presence of either the 'delay dial' and PTS (prepare to send) signal to ensure that the incoming end is ready. Alternatively, the implementation can be configured to wait for a 'wink' from the incoming end before dialling. If it is required to recognise an actual dial tone before dia- lling, a 'call_openout()' may be made without any destination digits, then the B-channel may be monitored by an external speech processing card (or similar), then all destination digits may be supplied, either one at a time or all together, via 'call_send_overlap()'. If no digits are supplied within a minimum period (often 10 seconds), the far end may regard the channel as 'back-busied', and not accept subsequent incoming digits. The R1 protocol implemented requires the destination address to start with a KP signal, and end with a ST signal. If KP is included explicitly by the use of a 'K' at the from of the dia- lled number string, then the implementation will expect an expli- cit 'S' to terminate the string. If no 'K' is supplied, the implementation will send one automatically prior to any dialled digits, and will time out a 10 second timer after the last digit supplied, and send an ST automatically. This timeout can be modified via an -s switch, as 10 seconds will be too long for many purposes. Alternatively, an explicit 'S' may be supplied to end the signalling. After the ST signal has been sent, the event EV_OUTGOING_RINGING will be returned to the application. This is clearly a misuse of the name of this event as it is not the case that actual ringing has been detected, although it does indicate generally the same stage of signalling. Once connected, the outgoing end will survive meter pulses less than (a default of) 350mS wide, and if CNF_CALL_CHARGE has been used, the API will return the event EV_CALL_CHARGE to the appli- cation. As a result of detecting meter pulses, the implementation will take (a default of) 350mS to recognise a backward clearing condi- tion. When this is recognised, if the 'remote disconnect' fea- ture is activated in the driver, the outgoing end will await clearing from the API before sending a forward release. If the incoming end goes off-hook again and re-answers, the outgoing end will return to 'connected'. If 'remote disconnect' is not enabled, the outgoing end will release immediately. 8 Configuration Switch Settings for R1EM This sections details the CONFIG.SYS switch settings (and confi- guration string switches for UNIX), for various optional features in PD1. The use of these switches within CONFIG.SYS will be similar to the following:- device = c:\sys\mvclcas.sys -p380 -i10 -s16 -s17 -s18 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 -s17n0. Simply using a switch with no comma and argument is equivalent to using an argument of 1 (as in s17,1). The maximum value of argument that may be used is 255 (as in s17,255). The switches that are applicable to EEMA are as follows:- -s1 Informs the protocol that it must always send a wink on incoming calls, and must always wait for a wink before dialling on outgoing calls. The timing for sending the wink is as set by -s3 and -s4. -s2,1 Enable generation of ringback on incoming calls as a result of calling the API function call_incoming_ring- ing(). The ringback cadence is a single cadence of 440Hz at -3.5 dBm0, 1S on and 3S off. No ringback is generated if -s98 is used. -s2,2 Enable generation of ringback on incoming calls as a result of calling the API function call_incoming_ring- ing(). The ringback is a dual cadence of 440Hz at -3.5dBm0, .4S on, .2S off, .4S on, 2S off. No ringback is generated if -s98 is used. -s3,nn If -s1 is set, this switch overrides the default 100mS delay on incoming calls before sending the wink. The new delay will be nn*10 mS. -s4,nn If -s1 is set, this switch overrides the default of 150mS for the duration of the wink on incoming calls. The new duration will be nn*10 mS. -s5,nn Provides an override to the default delay of 135mS on outgoing calls waiting for the delay dial/PTS signal, and is effectively a pre-dial delay. The new delay will be nn * 10mS, so to produce a 500mS wait for PTS, set -s5,50. -s6,nn On outgoing calls, causes ST to be sent, and the event EV_OUTGOING_RINGING to be automatically generated nn * 100mS after the last digit has been sent, and the supply of further digits via call_send_overlap() is not possible. If this switch is not set, a default timeout of 10 seconds will exist (as a defence mechanism). -s7 If this switch is used, then 'K' for KP and 'S' for ST will be included in the incoming DDI digit string. -s10 If this switch is set, it allows the incoming end to send ringing or to answer calls before an ST is received, although subsequent received digits will be lost. -s16 Generates dialtone on incoming calls, between the initial seize and recognition of KP. The dialtone is a constant mixture of 330Hz and 440Hz each at -10dBm0. No tones are generated if -s98 is used. -s25 Enables the generation of meter pulses on incoming calls, which are otherwise not passed from the API. -s25,nn Enable the generation of meter pulses, and overrides the default meter pulse length of 150mS. The new value set is x * 10mS. -s26 Enables the detection of meter pulses on outgoing calls, and considers that pulse lengths less than 350mS are meter pulses, and pulses over 350mS are clearing. -s26,nn Enables the detection of meter pulses on outgoing calls, and modifies the default detection period to nn*10mS. -s28,nn Overrides the default DTMF on/off time. The time is calculated as x * 5mS, and the default value is 70mS. -s31 Modifies the default delay (in 100mS increments) when a comma ',' is encountered in the destination address for dialling. To set a delay of 1.5 Secs, for example, use -s31,15. The default value for a single comma is 1 Sec. -s98 Prevents the firmware from accessing the DSP on the card, thereby making it safe to allow the use of the firmware on a card not fitted with a DSP. If this switch is used, the protocol will neither generate nor detect tones, so external tone signalling must be used. NOTE: If there is no DSP present and this switch is not set, the card will not start, and device driver initia- lisation will fail. -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. 9 Standard Switch Settings This section lists switch settings for commonly encountered signalling systems. Always optional -s2 -s6 -s7 -s16 " " -s25 -s26 -s28 -s31 E&M 'immediate start' (none) optional -s5,nn E&M 'delay dial' (none) optional -s5,nn E&M 'wink start' -s1 optional -s3,nn -s4,nn -s5,nn 10 Auto Back-Busy Option Switch The device driver auto back-busy option is available on the EEMA firmware and the associated CAS driver software, whereby channels not 'open_for_incoming' will automatically present back-busy (which will not be recognised as such for a short period of time, as it initially looks like an incoming seize). 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 only) -cBBY,0000FFFFn0 selective back-busy, affects port 0 (timeslots 1..15 only) -cBBY,FFFF0000n1 selective back-busy, affects port 1 (timeslots 17..31 only) 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, so in that respect FFFEFFFE and FFFFFFFF are equivalent. * * *