Subject: [AVT] V.8bis messages in RFC 2833bis

From: Tom Taylor <[email-masked]>
Date: Thu, 13 Nov 2003 19:13:06 -0600

While rewriting RFC 2833bis I found that the use of V.21 events with 
V.8bis signalling was underspecified.  V.21 simply transmits bits at 300 
bits/s using pure tones of specified frequencies to represent "0"s and 
"1"s.  (V.21 has two channels, but that is irrelevant here.)  A V.8bis 
message is a sequence of octets, where the carried information is 
preceded by HDLC flags and succeeded by a checksum and more HDLC flags. 
  To prevent false identification of HDLC flags within the carried 
information, extra zeros are inserted after sequences of five "1"s and 
stripped out again at the receiving end.

It doesn't seem necessary to carry the HDLC flags, and probably not the 
checksum (assuming redundancy encoding provides a sufficient degree of 
reliability).  The HDLC flags represent a minimum of 24 bits and a 
maximum of 64, each one of which is a separate event.  The checksum adds 
another 16 bits.  Zero stuffing adds some more.

Are there any existing implementations, and do they transmit the flags 
and checksum or not?

On a related topic, how many V.21 bits should be reported per packet, 
given that they are propagated at 33 ms intervals?  Any recommendation?

Tom Taylor

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Tom Taylor <[email-masked]>
Date: Mon, 17 Nov 2003 11:49:26 -0500

I've swung the other way in my thinking.  It seems to me the most common 
application for 2833 data events will be that of an IP bridge between 
two PSTN terminals.  This means the signalling should be such as to 
require a minimum of application knowledge at either gateway.  So Every 
bit should be passed along faithfully.

There is a problem with V.8bis signals (as opposed to messages).  The 
signals consist of two tone segments: 400 ms of dual-frequency tone that 
indicates only which party is sending, followed by 100 ms of 
signal-specific single tone.  With the present set of V.8bis events, 
that means the sender has to wait something in excess of 400 ms before 
indicating what event is happening.  The receiver starts playout 400+ ms 
late.  I'm not sure if that has harmful effects -- the timing does not 
seem to be a problem in V.8bis itself, but maybe in interoperation with 
older modems ...

Anyway, a V.8bis signal is often followed by a preamble tone and then by 
a V.8bis message (i.e. sequence of V.21 bits, as dicussed in my note 
below).  The implication of the 400+ ms delay is that down the line, the 
receiver is going to have to buffer up to 150 bit events for playout 
when their time comes.  I'm putting text in 2833bis to warn of this, but 
it seems to me matters could be improved if we added one or two events 
to indicate that segment 1 signal playout has begun.  This would mean 
the receiver would only be behind by the amount of time the sender 
needed to recognize the tone and send out the initial message.

Any comments by people who have done some implementation?

---

From: Stephen Casner <[email-masked]>
Date: Mon, 17 Nov 2003 10:27:35 -0800 (PST)

> bit should be passed along faithfully.

I agree with the penultimate sentence, but would modify the last one
to say ever _tone_ should be passed along faithfully.  As I argued a
few meetings back, 2833 is a means to encode signaling tones more
accurately and with fewer bits than low-data rate voice encodings can
do.  It is not a data transport.

                                                        -- Steve