Subject: FSK tones

From: Marty Borden <[email-masked]>
Date: Fri, 20 Aug 1999 15:12:21 -0400

I would like to bring for consideration another type of tone
that is for messaging in the tones draft.  These are the messages
that are done using Frequency Shift Keying, sent from a 
telephony switch.  Probably the most familiar of these is
the caller id message.  These messages have strict timing 
requirements.

I've written some introductory text on this:

===begin text
Calling Information Delivery Events

Some events are transmitted from a switch to the callee as additional
services that require strict timing.  The specific nature of these
events may be country specific.

For example, Calling Number Delivery (CND), also known as Calling Line
Identification (Caller-ID) service, allows the subscriber terminal to
display the calling party's directory number while the phone is
ringing. Also included in the received message is the date and time of
the call. In North America, the Caller ID information must be
transmitted in the silent interval between the first and second rings,
at least 500ms after the first ring and finishing at least 200ms
before the second ring.

CND is supported using a Frequency Shift Keying (FSK) encoding of
ASCII characters.  Here, two tones are used: a logical "1" (mark) and
a logical "0" (space). In the North America, Caller ID is based on the
same frequencies, modulation type and data format as Bell type 202
modems, using 1200 Hz for mark and 2200 Hz for space.  The message
payload can consist of up to 255 bytes.

Some other calling information delivery events are calling identity
delivery on call waiting, calling name delivery and visual message
waiting indication.  These are all transmitted using an FSK encoding
of ASCII data.
===end text

I could use some help on the encoding and international issues.

The simplist way to send the message, of course, is to send the
message type and the ASCII text.  However the tone representation
would be awkward.

It does not seem to me to be good to send a list of all the tones,
which could be 255 * 8 tones long.  There are really only 2 
frequencies involved.  In fact here is how it works for caller id
in the US:
   channel siezure signal - 30 consecutive bytes of 55h (01010101b) 
   carrier signal - 130 ms +/- 25 of mark signal (logical "1") at 1200 Hz 
   message type - one byte
   message length
   message data
   checksum.

It seems to me that since the message itself would carry the ascii
encoding, for the tones portion, we would need only to indicate the
'mark' and 'space' frequencies, their durations and the required
spacing between them.

I am interested in any comments or suggestions on this.  Are there
opinions on the encoding?  Is this adequate to handle international
messages?

Marty Borden
[email-masked]

References 

GR-30-CORE, Voiceband Data Transmission Interface Generic
Requirements, Issue 2, Bellcore, December 1998.  (In particular,
section 6.6)

TR-NWT-000031, CLASS(sm) Feature: Calling Number Delivery, FSD
01-02-1051 (A module of LSSGR, FR-NWT-000064), Issue 4, Bellcore,
December, 1992.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 24 Aug 1999 15:51:20 -0400

> 'mark' and 'space' frequencies, their durations and the required

These frequencies are already included in the "data" section of the
draft. I believe the FSK is the same as V.21:

signal                      code
V.21 channel 1, ``0'' bit   37
V.21 channel 1, ``1'' bit   38
V.21 channel 2, ``0'' bit   39
V.21 channel 2, ``1'' bit   40

Not sure which channel is used for caller ID.

As you say, sending the bits one at a time would seem to be awkward.
However, encoding ASCII (upper and lower case?) would seriously eat into
the available 8-bit codespace. 

It might be argued that this type of information really belongs into
RTCP, as an SDES 'NAME' item. RTCP has its own reliability mechanism
(retransmission) and I'd rather not duplicate the functionality. As soon
as you remove the strict bit timing and go to sending ASCII, sending it
in RTP doesn't seem all that necessary.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs