Generic E&M CAS Protocol 2.9 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 'EEMA', 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 signalling, one having been taken from an L.M. Ericsson specification document called "Digital Channel Associated Signalling for Private Net- works E/M Format", from Section 3 titled "Signalling Format 1 (A - Format)", which appears to be revision A, dated 07-Dec-1988. Other variants implemented by this firmware are E&M 'wink start, E&M 'immediate start' and DC5 protocols. The signalling protocol is a 1-bit (A-bit) protocol, and so is somewhat sparse in features, and depends somewhat upon timing. The implementation described here uses either DTMF or decadic pulsing for register signalling (although MFC is declared to be an optional alternative in the Ericsson documentation, it is not implemented here). The source specification documents are (as usual) less than thor- ough in its treatment, leaving a number of issues open for inter- pretation. Aculab Ltd would be grateful for any error reports generated as a result of the use of this protocol. 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 or decadic) Overlap Sending (DTMF or decadic) Recognition of EOS (end of sending) Recognition of Charging Pulses (optional) Call Release Remote Disconnect on Release (optional) Incoming Recognition of seize, optional wink generation Generation of two alternate dial tones (optional) Call Accept, with DDI digits (DTMF or decadic) Generation of EOS (optional) 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 (although, if the register signalling is deca- dic only, this is not an issue). 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 back-busy) and if pre- sent, 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'. 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 optionally generate one of two ring tone cadences whilst waiting for answer, optionally prece- ded by an EOS 'end of selection' signal if the appropriate '-s' switch is set, then 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, no 'end of selection', 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 do 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 400Hz at -10dBm0, which may be switched on and off (using 'set_output()' with mode=PATTERN_MODE and pattern=0x54, silence) to any (possibly multiple) B channels to produce other call progress tones, via an appropriate cadence. Relevant BS 6305 cadences are as follows:- Number engaged (BUSY) .375S on, .375S off Path engaged (congested) .4S on, .35S off, .225S on, .525S off Number unobtainable (NU) continuous 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. On outgoing calls, the implementation will recognise the EOF 'end of selection' signal, and cease further DTMF digit sending, and cause the event EV_OUTGOING_RINGING to be returned to the appli- cation. 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 part of signalling. On a service with no EOS signal, it may be useful to know when all DTMF digits have been sent. A configuration switch is available to cause a 'fake' EV_OUTGOING_RINGING to be returned when all of the digits currently known by the card have been sent. If subsequent digits are sent using 'call_send_overlap()', those digits may or may not be included prior to EV_OUTGOING_RINGING, depending upon when they are received from the API by the card. (Note that the use of the terms 'en-bloc' and 'overlap' in this connection is inappropriate, as all digits are sent individually and no true en-bloc sending is possible). 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 EEMA 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 an EC variant of a single cadence of 425Hz at -4.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 the UK standard dual cadence of a mixture of 400Hz and 450Hz each at -10dBm0, .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 the event EV_OUTGOING_RINGING to be automatically generated nn * 100mS after the last digit has been sent, although the supply of further digits via call_send_overlap() is still possible. -s8 On incoming calls, causes an EOS (end of selection) pulse to be sent when call_incoming_ringing() is called. The default period is 70mS. -s8,nn Overrides the default length of EOS, the new length will be nn*10 mS. -s9,nn Overrides the default value of the pre-dial and inter- digit delay for decadic dialling. The delay is calcu- lated as x * 10mS, and the default value is 750mS. -s10 Inverts the A bit signalling. Normally, A==1 for on- hook, and A==0 for off-hook (seized). With this switch set, A==0 for on-hook, and A==1 for off-hook (seized). Not normally required. -s11,x Modifies the default 100mS release guard time (ie. the time between clearing and allowing a subsequent outgoing seize) to x * 100mS. So for a guard time of 1 second, use -s11,10. -s16,1 Generates an EC variant dialtone on incoming calls, between the initial seize and recognition of the first dialled digit. The dialtone is a constant 425Hz at -11dBm0. No tones are generated if -s98 is used. -s16,2 Generates BS dialtone on incoming calls, between the initial seize and recognition of the first dialled digit. The dialtone is a constant mixture of 350Hz and 440Hz each at -10dBm0. No tones are generated if -s98 is used. -s17 Recognise decadic dialling on incoming calls as well as DTMF digits. Should be used if -s98 is used, otherwise no register signalling is possible. -s18 Force decadic dialling on outgoing calls on all channels. Should be used if -s98 is set, as otherwise no register signalling is possible. -s25 Enables the generation of meter pulses on incoming calls, which are otherwise not produced. -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 decadic dialling is the only option. 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 -s9 -s16 -s17 -s18 " " -s25 -s26 -s28 -s31 DC5 (SSDC5) (none) optional -s5,nn E&M 'immediate start' (none) optional -s5,nn E&M 'wink start' -s1 optional -s3,nn -s4,nn -s5,nn Ericsson E&M type A (none) optional -s8 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. * * *