home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
OS/2 Shareware BBS: 29 Fixes_o
/
29-Fixes_o.zip
/
ur458017.dsk
/
EEMAREL.TXT
< prev
next >
Wrap
Text File
|
1996-07-17
|
24KB
|
499 lines
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.
* * *
