IrEVENTS.4 Manual Page

NAME
IrEVENTS - IRAPI events

SYNOPSIS
#include <irapi.h>

DESCRIPTION
The event structure is used to pass information describing
an event from IRAPI to the calling process. It is defined
as:

typedef struct ir_event {
channel_id cid;
int event_id;
int tag;
int event_mod1;
int event_mod2;
int event_mod3;
int event_mod4;
int event_text_len;
void *event_text;
} ir_event_t

The ir_event modifiers are:

cid Specifies the channel identifier associated
with the event. This member is always
included. Set this value to IRD_NULL if not
applicable.

event_id Indicates which event (IRE_*) occurred.
These are symbolically defined and are listed
below. This member is always included.

tag Specifies an identifier passed by the appli-
cation with the asynchronous routines. Its
value is defined only when an event affects a
previous request that includes the value tag.
If no tag is associated with the event, tag
is set to -1.

event_modN Specifies up to four codes (event_mod1
through event_mod4) that provide more
detailed information on the event. These
members are not defined for all events. Any
event modifiers not used are set to
IREM_NULL.

event_text_len Specifies the length of event_text. Set this
value to 0 if it is not used.

event_text Specifies a pointer to an area of arbitrary
data whose interpretation is event dependent.
IRAPI will set this value to IRD_NULL if it
is not used. The contents of event_text will
change after every call to irWCheck() or
irWait() An IRAPI application should copy the
contents event_text before calling these
functions again. An IRAPI application must
not otherwise manipulate this memory, i.e.,
it should not call free() or realloc() with
this pointer.

Note: The internal IRAPI event queue adds a null byte to the
end of event_text data to ensure that strings stored in this
buffer are null terminated. The actual size of the data
pointed to by event_text is always event_text_len + 1.

Events are used to inform the application about completion
of activities, failures to complete an activity, intermedi-
ate activity progress, network conditions, or caller input.
An application can disable an event by masking it. To mask
an event, an application would call irSetEvent() with the
event action set to IRF_IGNORE. Events can be used to
interrupt activities by setting the event action to an OR'd
list of action flags. By default, most event actions are set
to IRF_NOTIFY.

Following is a list of IRAPI events and their associated
modifiers. Each event includes whether it can masked or
not. Event actions are set to IRF_NOTIFY by default. Excep-
tions are noted where appropriate.

IRE_ANSWER_DONE
This event is non-maskable. This event indi-
cates the completion of a request to answer a
call via irAnswer(3IRAPI).

IREM_COMPLETE This event modifier indicates
that the answer completed suc-
cessfully and the cid was put
into a IRD_ACTIVE channel ser-
vice state. In most cases
event_mod2 will have the value
of IREM_NULL, but event_mod2
might have the value of
IRER_REDUNTANT indicating that
the call had already been
answered and this call to
irAnswer was redundant. This
could occur in the case of
glare or other special cir-
cumstances. It might also be
a sign of a minor application
error.

For PRI, the event_text field will usually
contain the message that reported the answer
detection. Advanced PRI applications may
wish to parse the message for additional
information, but most applications will not
need to.

IREM_ERROR This event modifier indicates
the request terminated due to
error. event_mod2 (and possi-
bly event_mod3) contain error
code values that may help
resolve the problem. See
IrERRORS(4IRAPI) for possible
values. No change in channel
service state occurred.

IRE_BACKGROUND This event is maskable. This event indicates
the results of a request to start background
play on a particular channel.

IREM_COMPLETE This event modifier indicates
that the background play was
initiated successfully.

IREM_INTERRUPT This event modifier indicates
that the background play was
interrupted. This is likely
due to a hardware failure or
resource removal.

IRE_BOARD_DENY This event is non-maskable. A request to
remove a board from service has been denied.
This event is only expected by MTC and
related processes that take boards out of
service. The board that has been denied is
identified by event_mod1.

IRE_BOARD_GRANT
This event is non-maskable. A request to
remove a board from service has been granted.
This event is only expected by MTC and
related processes that take boards out of
service. The board that has been granted is
identified by event_mod1.

IRE_CALL_DONE This event is non-maskable. This event indi-
cates the request to make an outbound call
via irCall(3IRAPI) completed. The tag for
this event is the tag provided as an argument
to irCall. Event modifiers are identical to
those used for IRE_CALL_PROG. The distinc-
tion between IRE_CALL_PROG and IRE_CALL_DONE
is that IRE_CALL_DONE indicates that the
irCall request has completed. IRE_CALL_PROG
indicates intermediate events occur during
the call whether a irCall is active or not.

For PRI, the event_text field will usually contain the mes-
sage that reported the call completion. Advanced PRI appli-
cations may wish to parse the message for additional infor-
mation, but most applications will not need to.

IRE_CALL_PROG This event is maskable. This event occurs
when a call progress tone or message has been
detected. The tag for this event is unde-
fined (most likely set to 0) since it is
ambiguous as to what tag would apply to the
event. For PRI, the event_text field may
contain the message that reported the call
progress. Advanced PRI applications may wish
to parse the event_text field for additional
information, but most applications will not
need to. Event_mod1 for this event contains
the specific tone or message received:

IREM_RINGBACK This modifier to the
IRE_CALL_PROG event occurs for
each detected ring returned by
the network. An IREM_RINGBACK
is currently only expected
with analog (tip/ring) chan-
nels. When provided as a
modifier to the IRE_CALL_DONE
event, this means that the
first audible ring was
detected while
IRP_OUTCALL_MAXRINGS was set
to 0.

WARNING: The audible ring
heard by the called party may
occur at a different time than
the ringback provided via the
network. If the called party
answers the call on or before
the first audible ring, it is
possible that the VIS never
receives a ringback from the
network. Therefore, applica-
tions that depend upon receiv-
ing one or more IRE_CALL_PROG
or IRE_CALL_DONE events with
the IREM_RINGBACK modifier may
fail to detect that the called
party has answered the phone.

IREM_ERROR This event modifier occurs if
there is an error. event_mod2
(and possibly event_mod3) con-
tain error code values that
may help resolve the problem.
See IrERRORS(4IRAPI) for pos-
sible values. If the event_id
is IRE_CALL_DONE, the irCall
request has been aborted and
the service state may have
been modified. If the
event_id is IRE_CALL_PROG, an
error has been detected and
call completion analysis (if
enabled) most likely has been
stopped. The application
should take appropriate
recovery steps.

IREM_DENY This event modifier indicates
that the requested action
failed as the necessary
resources could not be
obtained within the interval
specified. This modifier is
expected on an IRE_CALL_DONE
when a pending request for CCA
resources is denied after a
timeout.

event_mod2 may contain addi-
tional information about the
reason for the denial.
IRER_RTU_BUSY indicates that
the necessary Feature License
did not become available
within the specified timeout
period. IRER_RESOURCE_BUSY
indicates that the necessary
resource did not become avail-
able in the specified timeout
period (but the Feature
License was available).
IREM_NULL indicates no further
information about why the
resource was not available.

IREM_CCA_BUSY This event modifier indicates
that CCA resources were
depleted. This is slightly
different than IREM_DENY in
that it indicates the Resource
Manager (RM) thought the CCA
resources were available, but
the CCA packfile thought that
the SP circuit card was
already fully used.

IREM_CHAN_REMOVED
This event modifier only
applies to irInitCall or irIn-
itCallGroup. It indicates
that the channel used for an
outbound call attempt has been
removed for use by another
process. When the event_id is
IRE_CALL_DONE, the outbound
call attempt has failed. When
the event_id is IRE_CALL_PROG,
the IRAPI library is automati-
cally trying another channel
in the group specified as an
argument to irInitCallGroup.

IREM_COT This event modifier indicats
that an outbound call has
failed since SS7 continuity
checking needs to continue on
the channel used for the out-
bound call. When the IREM_COT
modifier is received for an
IRE_CALL_DONE event, the
application should release the
channel by calling irDeinit.
In general, the application
should attempt to place the
outbound call on another
channel. When the IREM_COT
modifier is received for an
IRE_CALL_PROG event, it means
that irInitCallGroup encoun-
tered interference from con-
tinuity testing on one chan-
nel, has automatically called
irDeinit to release the chan-
nel, and has gone ahead to
attempt using another channel
in the group. This event
modifier is only expected on
SS7 channels and does not by
itself imply a problem in the
voice system or connections to
the switch.

IREM_GLARE This event modifier indicates
that an outbound call has
failed since there is an
incoming call on that channel.
When the IREM_GLARE modifier
is received for an
IRE_CALL_DONE event, the
recommended action is to call
irExecDefOwn with a svc_type
argument of IRD_AD_STARTUP to
release the channel and then
allow the Application Dispatch
(AD) process to pass the call
to an application to answer
the incoming call. In gen-
eral, the application should
attempt to place the outbound
call on another channel.

When the IREM_GLARE modifier
is received for an
IRE_CALL_PROG event, it means
that irInitCallGroup encoun-
tered glare on one channel,
has automatically called irEx-
ecDefOwn to release the chan-
nel back to AD, and has gone
ahead to attempt using another
channel in the group.

For Tip/Ring channels, the
event_mod2 value can be used
to determine the type of glare
condition that was encoun-
tered. IREM_NO_DIALTONE
indicates that no dialtone was
detected within
IRP_TR_GLARE_TIMEOUT seconds
of going off-hook. IREM_TT
indicates that a touch tone
was received after going off-
hook and before hearing dial-
tone or dialing digits (the
digit received is in
event_mod3). When IREM_TT is
reported, the digit will be
placed on the input queue and
an IRE_INPUT event will be
queued up to follow this
IRE_CALL_DONE event. If an
irExecDefOwn is done, the new
channel owner will unfor-
tunately not get the IRE_INPUT
event, but the input queue
will contain the touch tone
digit that was received. An
event_mod2 of
IREM_CALLINFO_ARRIVED indi-
cates that call information
arrived for the cid. The call
information id is in
event_mod3 and the irLBolt
time the call information was
received is in event_mod4.

For T1, E1, and PRI channels,
the event_mod2 value will be
IREM_NULL since there is only
one type of glare detection
for those telephony types.

IREM_GRANT This event modifier only
applies to IRE_CALL_PROG and
indicates that a pending
request for CCA resources
required for the call has been
satisfied. The state is
changing from IRS_CALL_PENDING
to IRS_CALLING.

IREM_REORDER This event modifier occurs if
there is a reorder tone (fast
busy).

IREM_HIDRY This event modifier occurs
when there is no line activity
for 25 seconds after a call
has been dialed.

IREM_DIALTONE This event modifier indicates
dial tone is detected. For
ISDN PRI, the ISDN cause value
is contained in event_mod2,
otherwise event_mod2 is
IREM_NULL.

IREM_STUTTER_DIALTONE
This event modifier indicates
stutter dial tone is detected.

IREM_MODEM This event modifier occurs if
a modem tone is detected.

IREM_DIALDONE This event modifier occurs
when dial is complete during
the irCall(3IRAPI).

IREM_BUSY This event modifier occurs if
a busy tone is detected. For
ISDN PRI, the ISDN cause value
is contained in event_mod2,
otherwise event_mod2 is
IREM_NULL.

IREM_FAST_BUSY This event modifier occurs if
"fast" busy tone is detected.
For ISDN PRI, the ISDN cause
value is contained in
event_mod2, otherwise
event_mod2 is IREM_NULL.

IREM_ANSWER This event modifier occurs on
answer detection (for example,
voice energy or cessation of
ringing detected).

IREM_ANSWER_SUP
This event modifier occurs on
answer supervision from the
switch.

IREM_TT This event modifier applies
only to IRE_CALL_DONE and
indicates that a touch tone
was detected (presumably indi-
cating that the call was
answered).

IREM_NOANSWER This event modifier occurs
when there is ringing, but no
answer after
IRP_OUTCALL_MAXRINGS. If
IRP_OUTCALL_MAXRINGS is set to
0, IREM_RINGBACK occurs rather
than IREM_NOANSWER.

IREM_RING_STOPPED
This event modifier occurs
when cessation of ringing has
been detected. This can gen-
erally be considered a form of
successful answer detection,
but does not indicate that
speech energy has been
detected. This modifier
currently only applies to LST1
or LSE1 (cessation of ringing
on T/R channels is reported as
an IRE_ENERGY event).

IREM_HUNGUP This event modifier occurs if
the orignal caller disconnects
(hangs up) while the applica-
tion is doing a transfer (via
irFlash and irDial).

IREM_TIMEOUT This event modifier occurs if
there is no call classifica-
tion after the timeout implied
by IRP_OUTCALL_MAXRINGS.

IREM_BLIND This event modifier indicates
the completion of a blind
call.

IREM_USER1 This event modifier is
reserved for customized appli-
cations and currently is not
implemented.

IREM_USER2 This event modifier is
reserved for customized appli-
cations and currently is not
implemented.

IREM_PROT_PROV This event modifier indicates
that there was an ISDN proto-
col or provisioning error.
The ISDN cause value is con-
tained in event_mod2.

IREM_INVALID_DIALSTRING
This event modifier indicates
that an outbound irCall or
irDial failed due to an
invalid dial string.

IREM_ISDN_VACANT
This event modifier indicates
that there was an ISDN vacant
code error. The ISDN cause
value is contained in
event_mod2.

IREM_SIT This event modifier indicates
special information tones and
primarily applies to using
Full CCA (that is, when
IRP_OUTCALL_CCALEVEL parameter
is set to IRD_FULL_CCA). It
can occur occasionally without
the use of Full CCA as
described below. Event_mod2
can be:

IREM_RO_INTRALATA
Intralata
reorder

IREM_RO_INTERLATA
Interlata
reorder

IREM_NC_INTRALATA
Intralata no
circuit

IREM_NC_INTERLATA
Interlata no
circuit

IREM_NC_INTL International
no circuit

IREM_VC Vacant code

IREM_IC Intercept

This event
modifier can
also be
reported on
Tip/Ring
channels
without use of
Full CCA. In
that case, it
represents a
non-SIT inter-
cept tone (such
as the one used
by most AT&T
PBX's to indi-
cate that an
invalid exten-
sion was
dialed).

IREM_FUTURE Future,
reserved

IREM_FF Foreign failure
(international)

IREM_OTHINTL International
other

IREM_OTHDOM Domestic other

IREM_OTHINEF Ineffective
other

IREM_UNKNOWN Unknown SIT
type

IRE_CHAN_DENY This event is non-maskable. This event indi-
cates the failed allocation of a channel to a
process as a result of a call to
irInit(3IRAPI3), irForceInit(3IRAPI) or
irInitGroup(3IRAPI) which returned
IRR_PENDING. After receiving the event,
processes should stop using the channel_id
returned from one of these functions as it is
invalid.

The event element cid is set to IRD_NULL. If
the event is the result of either
irInit(3IRAPI) or irForceInit(3IRAPI),
event_mod1 is set to the channel number
requested and event_mod2 is set to
IRD_INVALID. If the event is the result of
irInitGroup(3IRAPI), event_mod1 is set to
IRD_INVALID and event_mod2 is set to the
group number requested.

IRE_CHAN_GRANT This event is non-maskable. This event indi-
cates a channel has been allocated success-
fully to a process as a result of a call to
irInit(3IRAPI3), irForceInit(3IRAPI) or
irInitGroup(3IRAPI) which returned
IRR_PENDING.

IRE_CHAN_IS_DONE
This event is non-maskable. This event indi-
cates a request to place a channel in-service
via irChanIS(3IRAPI) completed.

IREM_COMPLETE This event modifier indicates
that the request completed
successfully and the cid was
put into a IRD_INACTIVE chan-
nel service state.

IRE_CHAN_OOS_DONE
This event is non-maskable. This event indi-
cates a request to place a channel out-of-
service via irChanOOS(3IRAPI) completed.

IREM_COMPLETE This event modifier indicates
that the request completed
successfully and the cid was
put into a IRD_CHAN_OOS chan-
nel service state.

For PRI, the event_text field
will usually contain the mes-
sage that reported the failure
to remove the channel from
service. Advanced PRI appli-
cations may wish to parse the
message for additional infor-
mation, but most applications
will not need to.

IRE_CHAN_REMOVED
This event is not maskable. This event
occurs when a channel is taken away from a
process. This can happen if the maintenance
process (MTC) removes a channel due to a user
request or a system hardware error, or when
another process requests a channel. When and
how channels are removed from a process may
be controlled to some extent by setting the
IRP_CHAN_NEGOTIATION parameter. See
irInit(3IRAPI) and IrPARAMETERS(4IRAPI). The
channel number is returned as event_mod1. An
application receiving this event should dis-
continue all use of the cid that was associ-
ated with the channel. The channel is deini-
tialized automatically, therefore irDeinit()
should not be called by the application.

IRE_CHAN_REQUESTED
This event is maskable. This event occurs
when a process requests a channel from an
application with the IRP_CHAN_NEGOTIATION set
to IRD_CONDITIONAL. The process receiving
the event may choose to release the channel
immediately via irDeinit(3IRAPI), complete
the call and/or do any post call processing
and release the channel, or completely ignore
the event, thereby denying ownership to the
requesting process.

IRE_CLOCK This event is maskable for cid based timers
only. This event occurs every time a
predesignated number of clock time units have
elapsed (timeout interval). The
irStartTimer(3IRAPI) function is used to
specify the time interval between successive
clock events on a given cid. The
irStartPTimer(3irPAI) function is used to
specify the time interval between successive
clock events on a process wide basis. The
subsequent IRE_CLOCK event has a valid cid
element only for timers started with
irStartTimer(3IRAPI) but not
irStartPTimer(3IRAPI). See irTimer(3IRAPI).

IRE_DEFOWNER This event is non-maskable. This event indi-
cates that a channel has just been returned
to its default owner. event_mod1 indicates
the channel number.

IRE_DEINIT_DONE
This event is maskable. This event, by
default, is set to IRF_IGNORE. This event
indicates that a channel has been idled and
released to the default owner or parent pro-
cess after execution of irDeinit(3IRAPI).
Note that the cid element in the event
structure is set to IRD_NULL since there is
no longer a cid associated with the channel.
event_mod1 contains the channel number
released. tag contains the tag passed to
irDeinit or irReturn.

This event is not generated if the calling
process never had ownership of the channel.
This would be the case if a process attempted
to gain ownership of a channel via
irInit(3IRAPI) and received an IRR_PENDING
return code, thereby placing the channel in
the IRS_INIT_PENDING state. If the channel
is released via irDeinit(3IRAPI) prior to
receiving an IRE_CHAN_GRANT, the release is
immediate and no IRE_DEINIT_DONE event is
generated.

IRE_DENY This event is non-maskable. This event indi-
cates a request for some resource was denied
after a resource request timeout.

event_mod1 may contain additional information
about the reason for the denial.
IRER_RTU_BUSY indicates that the necessary
Feature License did not become available
within the specified timeout period.
IRER_RESOURCE_BUSY indicates that the neces-
sary resource did not become available in the
specified timeout period (but the Feature
License was available). IREM_NULL indicates
no further information about why the resource
was not available.

This event applies to some but not all func-
tions returning IRR_PENDING where the pending
resource was not granted after the timeout
interval specified in
IRP_RESOURCE_RETURNMODE. The mutually
exclusive functions result in a DONE event
(for example, IRE_CALL_DONE) with an event
modifier of IREM_DENY rather than this
separate IRE_DENY event.

IRE_DIAL_DONE This event is non-maskable. This event indi-
cates a request to dial a string via irDial
completed.

IREM_COMPLETE This event modifier indicates
a dial request completed suc-
cessfully.

IRE_DISCONNECT This event is non-maskable. This event
occurs when disconnect is detected on a chan-
nel, but is not guaranteed to be generated
for all telephony interface types. The event
modifiers are a subset of those used for
IRE_CALL_PROG or IREM_NULL.

By default, the event mask is set to inter-
rupt outbound calls, and all play, say, and
record activity when this event occurs [event
mask set to (IRF_NOTIFY | IRF_CALLINTR |
IRF_PLAYINTR | IRF_RECINTR | IRF_SAYINTR).

Since this event is not generated for all
telephony interface types, an application
using those telephony interface types should
not depend on receiving an IRE_DISCONNECT for
all cases of the remote end terminating a
call. In particular, a T/R interface does not
have a reliable means of detecting a discon-
nect that is independent of the application.
Depending on the application, a disconnect on
a T/R interface may be indicated by an
IRE_WINK event or an IRE_CALL_PROG event with
an event modifier of IREM_DIALTONE,
IREM_STUTTER_DIALTONE, IREM_REORDER,
IREM_BUSY, or IREM_RINGBACK. The application
must determine whether such events represent
a disconnect or normal activity as part of an
irCall, irDial, or irFlash.

For PRI, the event_text field will usually
contain the message that reported the call
disconnect. Advanced PRI applications may
wish to parse the message for additional
information, but most applications will not
need to.

IRE_DISCONNECT_DONE
This event is non-maskable. This event indi-
cates a request to disconnect a call via
irDisconnect(3IRAPI) completed.

IREM_COMPLETE This event modifier indicates
the request to disconnect the
call completed successfully.
The channel service state has
changed to IRD_INACTIVE.

For PRI, the event_text field
may contain the message that
reported the failure to
disconnect properly. Advanced
PRI applications may wish to
parse the message for addi-
tional information, but most
applications will not need to.

IRE_DISCONNECT_TONE
This event is maskable. This event, by
default, is set to IRF_IGNORE. If the
IRE_DISCONNECT_TONE event is set to
IRF_NOTIFY (see irSetEvent(3IRAPI)), then an
application may receive this event (based on
the values specified in the irAPI.rc(4IRAPI)
file) instead of receiving the corresponding
IRE_CALL_PROG event when a ringing, busy,
reorder, dialtone, or stutter dialtone call
progress tone has been detected. Applica-
tions which have enabled this event should,
in general, treat it as an IRE_DISCONNECT
event. This event currently only occurs on
analog (tip/ring) channels. If an applica-
tion is performing outcalling by using
irAnswer(3IRAPI) instead of irCall(3IRAPI) or
is doing blind outbound calls with
irCall(3IRAPI), then it may receive an
IRE_DISCONNECT_TONE event that should not be
considered a disconnect event. Such applica-
tions should either set the IRF_IGNORE flag
or treat the IRE_DISCONNECT_TONE appropri-
ately based on the current state of the call.
The tag for this event is undefined (most
likely set to 0) since it is ambiguous as to
what tag would apply to the event.
Event_mod1 for this event contains the
specific tone received:

IREM_RINGBACK This modifier to the
IRE_DISCONNECT_TONE event
occurs for each detected ring
returned by the network.

IREM_REORDER This event modifier occurs if
there is a reorder tone (fast
busy).

IREM_DIALTONE This event modifier indicates
dial tone is detected.

IREM_STUTTER_DIALTONE
This event modifier indicates
stutter dial tone is detected.

IREM_BUSY This event modifier occurs if
a busy tone is detected.

IRE_ECHO_START This event is non-maskable. This event indi-
cates the results of an attempt to start echo
cancellation via irStartEcho(3IRAPI).

IREM_COMPLETE This event modifier indicates
the request to start the echo
canceler completed success-
fully. The channel is ready
to do speech recognition while
prompting.

IREM_ERROR This event modifier indicates
the request to start the echo
canceler failed. event_mod2
contains the error code and
event_mod3 may contain supple-
mental error code information.

IREM_DENY This event modifier indicates
the request to start echo can-
cellation failed due to echo
cancellation resources not
being available in the number
of milliseconds specified in
IRP_RESOURCE_RETURNMODE when
irStartEcho(3IRAPI) was exe-
cuted. event_mod2 may contain
additional information about
the reason for the denial.
IRER_RTU_BUSY indicates that
the necessary Feature License
did not become available
within the specified timeout
period. IRER_RESOURCE_BUSY
indicates that the necessary
resource did not become avail-
able in the specified timeout
period (but the Feature
License was available).
IREM_NULL indicates no further
information about why the
resource was not available.

IRE_ECHO_STOP This event is non-maskable. This event indi-
cates that echo cancellation has been
stopped.

IREM_COMPLETE This event modifier indicates
echo cancellation has been
successfully stopped. This is
the normal result of stopping
echo cancellation via
irStopEcho(3IRAPI).

IREM_ERROR This event modifier indicates
echo cancellation has been
stopped due to an error.
event_mod2 (and possibly
event_mod3) contain error code
values that may help resolve
the problem. See
IrERRORS(4IRAPI) for possible
values. When event_mod2 is
IRER_RESOURCE_REMOVED, it
indicates that echo cancella-
tion resources were forcibly
removed by a maintenance pro-
cess.

IRE_ENERGY This event is maskable. This event occurs
when speech energy is detected on the channel
while irStartSpeechED is active. event_mod1
contains the original event channel number.
event_mod2 contains the original event
recipient's qkey value.

For historical reasons, it may also occur
when cessation of ringing is detected by a
T/R card while irStartSpeechID is inactive.
In the future, a different event may
represent cessation of ringing (eg.
IRE_CALL_DONE or IRE_CALL_PROG with
IREM_RING_STOPPED modifier).

IRE_EVENT_MONITOR
This event is non-channel based and is there-
fore non-maskable. This event indicates that
an event specified for monitoring via
irEventMonitor(3IRAPI) has occurred.

event_text contains a pointer to the event
being monitored. Beware that any pointer
values in the monitored event are only valid
within the context of the process receiving
the original event at the time the event is
reported.

IRE_EXCEPTION This event is not maskable. This event
occurs when an asynchronous failure happens
and must be reported to the application so
the application may take appropriate action,
i.e., terminate the call. Event_mod1 indi-
cates the class of error as follows:

IREM_BRIDGE This event modifier indicates
a card does not have enough
resources to complete a bridge
request made to it.
Event_mod2 indicates the chan-
nel number that could not be
bridged. Event_mod3 indicates
the reason for the failure.
Event_mod4 indicates the
number of IRE_EXCEPTION events
the application has been sent
so far.

IREM_RESOURCE This event modifier indicates
a card does not have enough
resources to complete a
timeslot connect request made
to it. Event_mod2 indicates
the channel number of the
timeslot connect request.
Event_mod3 indicates the rea-
son for the failure.
Event_mod4 indicates the
number of IRE_EXCEPTION events
the application has been sent
so far.

IRE_EXEC This event is not maskable. This event
occurs when an application has been
irExec(3IRAPI)'ed or irSubProg(3IRAPI)'ed on
a channel. event_mod1 is the channel number.
event_mod2 is IREM_SUBPROG if the event is
the result of an irSubProg(3IRAPI) call, or
IREM_EXEC if the event is the result of an
irExec(3IRAPI) call. Applications are
expected to irInit(3IRAPI) the channel after
receiving this event. After successful ini-
tialization of the channel, the exec buffer
may be accessed though the IRP_EXEC_BUF
parameter.

IRE_EXTERNAL This event is maskable. This event occurs
when another process sends an event to the
IRAPI with irPostEvent(3IRAPI).
event_text_len contains the length of
event_text. event_text points to the message
header ( struct mbhdr ) and data passed by
irPostEvent(3IRAPI). See irPostEvent(3IRAPI)
for details.

IRE_FAXPRINT_DONE
This event is non-maskable. This event indi-
cates that a FAX print has completed.
Event_mod1 indicates the reason for the FAX
print completion as follows:

IREM_COMPLETE The FAX print request com-
pleted successfully.

IREM_ERROR The FAX print request ter-
minated due to error.
event_mod2 contains error code
values that may help resolve
the problem. See
IrERRORS(4IRAPI) for possible
values.

IREM_STOPPED The request was terminated due
to irStop(3IRAPI) or an event
interrupt.

IREM_DENY The request was terminated due
to a timeout on waiting for
FAX print resources.
event_mod2 may contain addi-
tional information about the
reason for the denial.
IRER_RTU_BUSY indicates that
the necessary Feature License
did not become available
within the specified timeout
period. IRER_RESOURCE_BUSY
indicates that the necessary
resource did not become avail-
able in the specified timeout
period (but the Feature
License was available).
IREM_NULL indicates no further
information about why the
resource was not available.

For IREM_COMPLETE, IREM_ERROR, and
IREM_STOPPED, event_mod3 contains the number
of pages printed, event_mod4 contains the
number of bytes printed, event_text contains
the job_id for this job as a character string
and event_text_len, is its length.

IRE_FAXPRINT_PROG
This event is maskable. This event indicates
that a FAX job ID is now available. The job
ID is a character string of length
event_text_len pointed to by event_text. The
size of the job ID will be at most
IRD_FAX_JOB_ID_LENGTH characters. Event_mod1
indicates the validity of the job ID as fol-
lows:

IREM_NULL Job ID is valid.

IREM_ERROR Job ID is not valid. Expect a
subsequent failure mode
IRE_FAXPRINT_DONE.

IREM_STOPPED Job ID is not valid. This
event will result if
irStop(3IRAPI)
was called or an event inter-
rupting FAX print was
received. Expect a subsequent
IRE_FAXPRINT_DONE with the
IREM_STOPPED modifier.

IRE_FAXRECORD_DONE
This event is non-maskable. This event indi-
cates that a FAX record has completed. The
number of bytes recorded is available from
irGetVCount(3IRAPI). Event_mod1 indicates
the reason for the FAX record completion as
follows:

IREM_COMPLETE The FAX record request com-
pleted successfully.

IREM_ERROR The FAX record request ter-
minated due to error.
event_mod2 contain error code
values that may help resolve
the problem. See
IrERRORS(4IRAPI) for possible
values.

IREM_PARTIAL The FAX record request com-
pleted prematurely due the
reason indicated in
event_mod2.

IREM_STOPPED The request was terminated via
user request ( irStop(3IRAPI))
or event interrupt.

IREM_DENY The request was terminated due
to a timeout on waiting for
FAX record resources.

For IREM_COMPLETE, IREM_ERROR, IREM_PARTIAL,
and IREM_STOPPED, event_mod3 contains the
number of pages recorded, event_mod4 contains
the number of bytes recorded, event_text con-
tains the remote tsi as a character string
and event_text_len, is its length.

IRE_FAX_TONE This event is maskable. This event indicates
that FAX tone has been detected. event_mod1
contains either IRF_CNG or IRF_CED for the
type of tone detected. FAX tone detection is
turned on. event_mod3 contains the duration of
the CNG tone in milliseconds. CNG tone duration
may be used to truncate a voice file recorded at
the time CNG tone is detected. The duration
indicated in event_mod3 should be truncated
from the end of the file (see F_FREESP). Note that
event_mod2 is unused, event_mod3
is used instead for backward compatibility reasons.

IRE_FLASH_DONE This event is non-maskable. This event indi-
cates a request to perform a hook flash.

IREM_COMPLETE This event modifier indicates
the request completed success-
fully.

IREM_ERROR This event modifier indicates
the request terminated due to
an error. event_mod2 (and
possibly event_mod3) contain
error code values that may
help resolve the problem. See
IrERRORS(4IRAPI) for possible
values.

IRE_GRANT This event is maskable. This event indicates
a request to reserve one or more resources
has been granted. This is a possible subse-
quent event for any function returning
IRR_PENDING.

IRE_INPUT This event is maskable. This event occurs
when any input is detected. Event_mod1 can
be:

IREM_TT For touch-tone input:
event_mod2 contains the
touch-tone digit [see
IrDIALSTRINGS(4IRAPI)],
event_mod3 contains the
sequence number, event_mod4
contains the lbolt time when
the touch-tone was received.
The tag event structure field
is not valid for IRE_INPUT
with the IREM_TT modifier.
NOTE: In the unlikely case of
glare being detected on
Tip/Ring channels by touch-
tones being received before
dialing an outbound call, it
is possible for an application
to miss the first IRE_INPUT
event when an IRE_CALL_DONE
event with IREM_GLARE and
IREM_TT modifiers causes the
prior channel owner to call
irExecDefOwn. The digit
received will however be on
the input queue.

IRE_INPUT_DONE This event is maskable. This event occurs
when the specified input parameters are
satisfied. That is, input exists on the
input queue such that a delimiter character
has been received, a specified number of
characters have been received, or an input
timeout has occurred. Note that
IRE_INPUT_DONE may or may not be associated
with a IRE_INPUT event. If parameters are
modified such that the current state of the
input queue meets the conditions specified in
the parameters, a IRE_INPUT_DONE event is
generated by the next call to irWait(3IRAPI).
The tag field of the event structure has no
meaning for this event. Possible values for
event_mod1 include:

IREM_INPUT_LENGTH
This event modifier occurs
when the number of input char-
acters as specified in
IRP_INPUT_LEN has been
reached.

IREM_INPUT_DELIM
This event modifier occurs
when the input string delimit-
ing character string as speci-
fied in IRP_INPUT_DELIM1 and
IRP_INPUT_DELIM2 is received.
event_mod2 marks the position
in the input queue where the
delimiter matches the input.

IREM_TT_PRE This event modifier occurs
when the IRP_TT_PRETIME inter-
val elapses after issuing
irStartTTTimer(3IRAPI) and no
input is detected.

IREM_TT_INTER This event modifier occurs
when the IRP_TT_INTERTIME
interval elapses after the
most recent input is received.

IREM_RECOG For speech or dial pulse
recognition input: event_mod2
indicates the disposition of
the recognition, either
IREM_COMPLETE or IREM_ERROR.
If IREM_COMPLETE, event_mod3
contains the number of charac-
ters placed on the input queue
as a result of this event, and
event_mod4 indicates the
recognizer. If IREM_ERROR,
event_mod3 (and possibly
event_mod4) contains the error
codes for failure. [NOTE: The
error codes are shifted down
by one modifier from the loca-
tions described in
IrERRORS(4IRAPI).] When
recognition input is received,
the tag field of the event
structure contains the value
of the tag used with
irStartRecog(3IRAPI). Note
that receiving this event
automatically turns off the
recognizer.

IREM_RECOG_PRE This event modifier occurs
when the IRP_RECOG_PRETIME
interval elapses after issuing
irStartRecogTimer(3IRAPI) and
no input is detected.

IREM_RECOG_INT This event modifier occurs
when the IRP_RECOG_INTTIMER
interval elapses since the
most recent utterance or dial-
pulse has been detected.
Similar to IREM_RECOG,
event_mod2 indicates the
disposition of the recogni-
tion, either IREM_COMPLETE or
IREM_ERROR. If IREM_COMPLETE,
event_mod3 contains the number
of characters placed on the
input queue as a result of
this event, and event_mod4
indicates the recognizer. If
IREM_ERROR, event_mod3 (and
possibly event_mod4) contains
the error codes for failure.

IRE_INTERRUPT This event is non-maskable. This event indi-
cates that while a process was waiting in
irWait(3IRAPI), it was interrupted by a UNIX
signal or some other interrupt. This event
may be used by a process to alert the process
of an interrupt. For example, by setting
signals, a process may force an exit from
irWait(3IRAPI) at appropriate times.

IRE_LOOP This event is maskable. This event occurs
when there is a change in loop current such
that the presence of loop current is
detected. This event, by default, is set to
IRF_IGNORE.

IRE_NETWORK_ERROR
This event is non-maskable. This event indi-
cates an error has been detected by the tele-
phone network or network interface card. In
most cases, the application should call
irDeinit to attempt to recover from the prob-
lem. Additional information about the error
can be found in event_mod2. When this error
occurs for a PRI channel, event_mod2 contains
the ISDN cause value or the SP PRI error
code. When this error occurs for an E1, T1,
LSE1, or LST1 channel, event_mod2 generally
contains the T1 driver error number. When
this error occurs for an ASAI channel,
event_mod2 contains IREM_HUNGUP when the ANI
or DNIS value has changed between the first
NEWCALL event and the attempt to answer the
call with irAnswer (this generally indicates
the first of two callers hung up before the
call was answered).

This event might be preceded by an
IRE_ANSWER_DONE, IRE_CALL_DONE,
IRE_CHAN_OOS_DONE, or IRE_DISCONNECT_DONE
with an event modifier of IREM_ERROR. If so,
the application may have already called
irDeinit(3IRAPI) by the time that this event
is received by the application. No harm is
expected if the application makes a redundant
call to irDeinit. This likely results in a
return of IRR_FAIL with irSysError set to
IRER_BADSTATE.

For PRI, the event_text field may contain the
message that reported the network error.
Advanced PRI applications may wish to parse
the message for additional information, but
most applications will not need to.

IRE_NEWCALL This event is non-maskable. This event indi-
cates a new call has come in on a channel.
An application that is exec-ed by the AD pro-
cess as a result of a new call sees this
event as the first message after doing
irInit. Most applications can safely ignore
this IRE_NEWCALL since the application is
probably written to answer the incoming call.
If the IRE_NEWCALL is received after discon-
necting from a call, the event indicates that
a second incoming call has arrived. Most
applications can deal with the second
IRE_NEWCALL by doing a irDeinit on the chan-
nel to allow AD to assign the call to the
proper application. If the irDeinit happens
automatically by other means, the second
IRE_NEWCALL can also be ignored.

For PRI, the event_text field will usually
contain the message that reported the incom-
ing call. Advanced PRI applications may wish
to parse the message for additional informa-
tion, but most applications will not need to.

IRE_NOLOOP This event is maskable. This event occurs
when there is a change in loop current such
that no loop current is detected.

IRE_NULL This event is non-maskable. No event has
occurred. The IRE_NULL event is generated
when irCheck(3IRAPI) is called with no event
queued.

IRE_PLAY_DONE This event is non-maskable. This event indi-
cates that play has completed. The amount of
time played is available from
irGetVCount(3IRAPI). Event_mod1 indicates
the reason for the play completion as fol-
lows:

IREM_COMPLETE The play request completed
successfully.

IREM_TALKOFF The play request was talked
off by caller input. If the
talkoff was due to an invalid
sequence number, then
event_mod2 will be set to
IREM_SEQNO. Otherwise,
event_mod2 will be set to
IREM_NULL.

IREM_STOPPED The play request was stopped
via a software message such as
irStop.

IREM_NODATA The play request specified
contained no data. This event
modifier indicates that voice
file descriptor(s) were repo-
sitioned via irLSeek(3IRAPI)
to the end of the file(s).

IREM_ERROR The play request terminated
due to error. event_mod2 (and
possibly event_mod3) contain
error code values that may
help resolve the problem. See
IrERRORS(4IRAPI) for possible
values.
IREM_HUNGUP Thie play request was abruptly terminated by the caller hanging up the phone.

IREM_DENY The request was terminated due
to a timeout on waiting for
play resources. event_mod2
may contain additional infor-
mation about the reason for
the denial. IRER_RTU_BUSY
indicates that the necessary
Feature License did not become
available within the specified
timeout period.
IRER_RESOURCE_BUSY indicates
that the necessary resource
did not become available in
the specified timeout period
(but the Feature License was
available). IREM_NULL indi-
cates no further information
about why the resource was not
available.

IRE_PLAY_PROG This event is maskable. By default, this
event is set to IRF_IGNORE. When repeated
play functions [irPlay(3IRAPI),
irFPlay(3IRAPI), irBPlay(3IRAPI)] are queued,
a single IRE_PLAY_PROG event occurs when each
intermediate play is finished, except for the
last one. The last event generates an
IRE_PLAY_DONE. Access irGetVCount(3IRAPI) to
determine the time played after each inter-
mediate play completes.

IRE_PRI_MSG This event is maskable. This event reports
PRI messages that were not internally pro-
cessed by the IRAPI library (messages that
were internally processed are reported via
event_text for IRE_ANSWER_DONE, etc). Typi-
cally this event will be seen for PRI mes-
sages such as FACILITY, FAC_ACK, FAC_REJ,
REGISTER, etc. Most applications can safely
ignore this event. Advanced PRI applications
may need to deal with this event to handle
special signaling messages provided by the
switch.

IRE_RECOGNIZING
This event is maskable. This event informs
the application that a recognizer has deter-
mined it has valid input, but before the
recognition has completed. event_mod1 indi-
cates the recognizer. An application can,
for example, turn off all other recognizers
that may be running on the same input, and
allowing the recognizing recognizer to con-
tinue.

IRE_RECORD_BUF This event is non-maskable. This event
informs the application that a buffer of
recorded speech has been placed in the area
pointed to by buf, buf is provided from an
earlier call to irBRecord [see
irRecord(3IRAPI)]. event_mod1 contains the
number of bytes copied to the area pointed to
by buf. The event tag is set to the tag used
in the call to irBRecord.

IRE_RECORD_DONE
This event is non-maskable. This event indi-
cates that the requested voice record com-
pleted. The amount of time recorded is
available from irGetVCount(3IRAPI). The
event_mod1 modifiers are as follows:

IREM_COMPLETE The record request completed
due to recording count mil-
liseconds of speech where
count was specified via the
irRecord function.

IREM_TALKOFF The record request terminated
due to caller input.

IREM_STOPPED The record request stopped via
a software message resulting
from irStop.

IREM_SILENCE The record request terminated
due to silence detection.

IREM_ERROR The record request terminated
due to error. event_mod2 (and
possibly event_mod3) contain
error code values that may
help resolve the problem. See
IrERRORS(4IRAPI) for possible
values.

IREM_DENY The record request timed out
while waiting for record
resources. event_mod2 may
contain additional information
about the reason for the
denial. IRER_RTU_BUSY indi-
cates that the necessary
Feature License did not become
available within the specified
timeout period.
IRER_RESOURCE_BUSY indicates
that the necessary resource
did not become available in
the specified timeout period
(but the Feature License was
available). IREM_NULL indi-
cates no further information
about why the resource was not
available.
IREM_HUNGUP The play request was abruptly terminated by the caller hanging up the phone.

IRE_REPORT_DISK
This event is non-maskable. This event is
generated in response a call to
irSPDReportDisk(3IRAPI). For this event, cid
is not defined. Event_mod1 contains the
number of purchased logical blocks available,
event_mod2 contains the total number of pur-
chased logical blocks in the speech file-
system(s), and event_mod3 contains the number
of bytes in each block.

IRE_RESERVE_DISK
This event is non-maskable. This event is
generated in response to a call to
irSPDReserveDisk(3IRAPI). For this event,
cid is not defined. Event_mod1 indicates the
disposition of the request as follows:

IREM_COMPLETE The specified number of bytes
was successfully reserved.
The path-name of the file-
system where the specified
number of bytes was reserved
is indicated in event_text.

IREM_ERROR The request could not be
satisfied due to insufficient
space.

IRE_RESERVE_DONE
This event is non-maskable. This event indi-
cates that a irPhReserve has completed.

IREM_COMPLETE The request has been completed
successfully.

IREM_ERROR The request terminated due to
error. event_mod2 (and possi-
bly event_mod3) contain error
code values that may help
resolve the problem. See
IrERRORS(4IRAPI) for possible
values.

IRE_RETURN This event is non-maskable. This event
indicates that a irSubProg has completed.

IREM_COMPLETE The request has been completed
successfully. event_mod2 con-
tains a return code passed by
the called application through
the value argument of
irReturn(3IRAPI) . tag con-
tains the tag passed to irSub-
Prog.

IREM_ERROR The request terminated due to
error. event_mod2 (and possi-
bly event_mod3) contain error
code values that may help
resolve the problem. See
IrERRORS(4IRAPI) for possible
values.

IRE_RESOURCE_REMOVED
This event is maskable. This event occurs
when a explicitly reserved dynamic resource
is removed from a channel due to a mainte-
nance process. If the resource was currently
being used, the activity making use of it is
stopped automatically. event_mod1 contains
the resource capability and event_mod2 con-
tains the implementation. See
IrRESOURCES(4IRAPI).

This event does not occur when implicitly
allocated resources are removed by a mainte-
nance process. Instead, the application
should expect to receive the associated done
or stop event with event modifiers of
IREM_ERROR and IRER_RESOURCE_REMOVED. (for
example, see IRE_PLAY_DONE and
IRE_ECHO_STOP).

IRE_REVERSE This event is maskable. This event is
reserved for future use to indicate that
current reversal has been detected on a chan-
nel.

IRE_SAY_DONE This event is non-maskable. This event indi-
cates that the request for TTS was completed.
The same event_mod1 modifiers apply for
IRE_SAY_DONE as were used for IRE_PLAY_DONE.
The number of bytes played is available
irGetVCount(3IRAPI) ( for the IRD_SWTTS
implementation of the IRC_TTS resource only).
The vcount value is also available in
event_mod4.

IRE_SAY_PROG This event is maskable. By default, this
event is set to IRF_IGNORE. When repeated
text to speech functions [irSay(3IRAPI),
irFSay(3IRAPI), irBSay(3IRAPI)] are queued, a
single IRE_SAY_PROG event occurs when each
intermediate say is finished, except for the
last one. The last event generates an
IRE_SAY_DONE. Access irGetVCount(3IRAPI) to
determine the number of bytes played after
each intermediate say completes. The vcount
value is also available in event_mod4.

NOTE: This event is only applicable when using the IRD_SWTTS
implementation of the IRC_TTS resource (see
IrRESOURCES(4IRAPI)).

IRE_LANGID_DONE
This event is maskable. By default, this
event is set to IRF_NOTIFY. This event indi-
cates the request to identify a language completed.
The event_mod1 modifiers are as follows:

IREM_COMPLETE The language identification
request completed success-
fully. Event_mod2 is the
recognized language and sub-
language of the text contained
in the buffer or file. The
values will be valid Microsoft
Speech API 4.0 language iden-
tifiers. Currently, the Ler-
nout & Hauspie language recog-
nizer will only detect sub-
languages in written text for
German (Standard or Swiss) and
Portuguese (Standard and Bra-
zilian). The language and
sub-language are encoded as
follows:

Bits 0 to 9 - language as identified in the
SAPI 4.0 specification and as supported by
the Lernout & Hauspie Language Recognition
engine.

unknown 0x00

Afrikaans 0x36
Albanian 0x1c

Arabic 0x01

Basque 0x2d

Bulgarian 0x02

Catalan 0x03

Chinese 0x04

Croatian 0x1a

Czech 0x05

Danish 0x06

Dutch 0x13

English 0x09

Estonian 0x25

Finnish 0x0b

French 0x0c

German 0x07

Greek 0x08

Hebrew 0x0d

Hungarian 0x0e

Illegal name 0x1a

Italian 0x10

Japanese 0x11

Korean 0x12

Lithuanian 0x27

Malaysian 0x3e

Polish 0x15

Portuguese 0x16

Rumanian 0x18

Russian 0x19

Spanish 0x0a

Swedish 0x1d

Thai 0x1e

Turkish 0x1f

Vietnamese 0x2a

Bits 10 to 15 - sub-language

For German:

standard 0x0400

Swiss 0x0800

For Portuguese:

European 0x0800

Brazilian 0x0400

Event_mod3 indicates the character code for
the given file or buffer of text. Character
code is a platform-specific encoding of a
character set, such as a certain
platform/code page. For example, MS-DOS code
page 437, MS-DOS code page 850, and MS Win-
dows code page 1252 have their own unique
character codes for many ISO Latin-1 charac-
ters.

Value Character Code

0 - 9 Illegal

10 Macintosh

11 MS-DOS, primary
code page

12 MS-DOS, secon-
dary code page

13 3MS-Windows

14 ISO

15 Illegal

16 KOI-8-r (??)

Event_mod4 indicates the character set for
the given file or buffer of text. Character
set is a platform-independent encoding
scheme; for example, ISO Latin-1, Unicode, or
Shift-JIS.

Value Character Set

0-1 Illegal

2 Shift JIS

3 Unicode

4 EUCF

5 EUCP

6 JIS

7 Big Five (Trad-
itional
Chinese)

8 GB-2312-80
(Simplified
Chinese)

9 KS C 5601-1992
(Korean)

10-15 Illegal

16 ISO 8859 - 1

17 ISO 8859 - 2

18 ISO 8859 - 3

19 ISO 8859 - 4

20 ISO 8859 - 5

21 ISO 8859 - 6

22 ISO 8859 - 7
23 ISO 8859 - 8

24 ISO 8859 - 9

25 Vietnamese IR
180

26-30 Illegal

31 Thai IR 166

32 Vietnamese VIQR

IREM_ERROR The language identification
request failed. event_mod2
and event_mod3 may contain
additional information about
the reason for the failure.

NOTE: This event is applicable only when using the IRD_SWTTS
implementation of the IRC_TTS resource (see
IrRESOURCES(4IRAPI)).

IRE_SOFTDISC The default event mask for this event is
IRF_DEINIT. The channel cid will automati-
cally be released (irDeinit(3IRAPI)) when
this event is received unless the default
event mask is changed. This event is gen-
erated by another process using the
irInterrupt(3IRAPI) function and generally
indicates that the application should ter-
minate and irDeinit(3IRAPI) the channel.
event_mod1 through event_mod3 are set to the
arg1 through arg3 arguments to
irInterrupt(3IRAPI), respectively.

Note: When this event is sent to TSM, it gen-
erates a ESOFTDISC event (see event()
instruction) for the script application.

IRE_SOFTINT The default event mask for this event is
IRF_IGNORE. The event will be ignored unless
the default mask is reset. This event is
generated by another process using the
irInterrupt(3IRAPI) function. event_mod1
through event_mod3 are set to the arg1
through arg3 arguments to
irInterrupt(3IRAPI), respectively.

Note: When this event is sent to TSM, it gen-
erates a EDIPINT event (see event() instruc-
tion) for the script application.

IRE_TS_DONE This event is non-maskable. This event indi-
cates an activity on a time slot completed. event_mod1
contains the time slot for which the activity
was started. event_text points to an event
structure (ir_event_t) containing the
IRE_<activity>_DONE event. For example, if
voice play was started, event_text points to
an ir_event_t structure containing a IRE_PLAY_DONE event and all
of its associated modifiers.

IRE_WINK This event is maskable. Occurs when a wink
is detected on a channel. This generally
indicates that the network has disconnected
an active call on a T/R channel.

IRE_USER[1-5] These events are maskable. These events are,
by default, set to IRF_IGNORE and may be used
for future extensibility.

CAVEATS
The IREM_USER1 and IREM_USER2 event modifiers to
IRE_CALL_PROG are used for customized tones, and may not be
supported by both Intuity and Intuity Conversant. The
mechanism for recognizing these customized tones is beyond
the scope of IRAPI. These event modifiers provide a hook
for IRAPI to be able to report the detection of them, once
recognized.

IREM_USER3, IREM_USER4 or IREM_USER5 may be used for future
extensibility.