User guide

114 RealCT Direct API Developer Guide
Chapter 4: E1 Networking
Sending Control Tones
In R2-CCITT protocols, your application emulates both the
receiving end CO and subscriber. The CO portion sends control
tones such as ringback and busy to indicate the status of the call
to the other end.
When a subscriber receives a call, the CO emulation part of the
application should determine the status of the line and send
either a busy or ringback tone back to the caller. It should also
send the hangup tone when the subscriber hangs up. Many
applications skip sending control tones and instead send the
answer signal immediately after receiving the incoming call,
leaving the line silent until the application is ready to start
playing prompts or a live person can handle the call. If a calling
party does not hear control tones, they might think the call was
lost and hang up, especially if the application had to perform a
lengthy task such as querying a data base or checking the status
of agents at a call center.
Sending control tones also improves the timing of the call if
there are many transit COs between the calling party and your
application. In this case, it could take several hundred
milliseconds to establish an audio path between the two ends. If
the application immediately begins playing audio prompts after
receiving a call, the caller could lose the first portion of the
prompt that was played while the audio path was being
established. Sending control tones establishes the audio path
before the application begins playing, so the caller hears the
entire audio prompt.
Although adding the control tones might add some complexity,
some countries require that your application meets some
minimum requirements before live traffic is routed to it.