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