Subject: [AVT] More on V.21 events

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

Thinking about V.21 a bit more, I realized that it isn't clear when an 
event should be rteported.  The choices are to report an event every 
time a bit is sent (i.e., 300 events per second), or else every time a 
transition occurs (which means something less than 150 events per 
second).  Of course, the event rate itself doesn't mean too much without 
also specifying the rate at which event updates are issued.  But if 
updates are issued every 66.7 ms or more, the number of event reports 
would be halved on the average.

So: should we specify one approach or the other, or allow either and 
require implementations to be able to handle events spanning multiple bits?

Tom Taylor

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

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Thu, 13 Nov 2003 20:11:00 -0600

Have you decided how you will report V.21 110 bits/second. It is used in
large parts of Europe and South America for text telephony.

( sorry, I should have read what applications are in scope before putting
this question, maybe it is totally out of scope that a textphone call needs
to be decoded and transmitted this way. )

Regards
Gunnar Hellstrom
-------------------------------------------
Gunnar Hellstrom
Omnitor AB
Renathvagen 2
SE 121 37 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204 288
www.omnitor.se
[email-masked]
--------------------------------------------

-----Ursprungligt meddelande-----
Fran: [email-masked] [mailto:[email-masked]]For Tom Taylor
Skickat: den 13 november 2003 19:44
Till: [email-masked]
Amne: [AVT] More on V.21 events

Tom Taylor

---

From: Tom Taylor <[email-masked]>
Date: Thu, 13 Nov 2003 20:28:21 -0600

I'll adjust the wording to allow for rates lower than 300 bits/s.  My 
original question still stands, but is perhaps less pressing at lower rates.

Actually, I'm in favour of requiring an event to be reported for each 
bit sent.  This increases redundancy in a natural manner, since event 
completions are transmitted redundantly.

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Thu, 13 Nov 2003 21:27:36 -0600

OK, fine.

You will have some nasty detection cases. Hope that detection precision is
good enough for that.

E.g. the 300 bps byte FA versus the 110 bit/s byte FF are quite close. ( if
I get bit-order right )

The 300 bps byte FA in V.21 lower channel is 980 Hz lead-in, 10 ms  of 1180
Hz, 29.7 ms of 980 Hz continued in 980 Hz until next character.

The 110 bps byte FF in lower channel V.21 is 980 Hz lead-in, 9.1 ms of 1180
Hz, 81,9 ms of 980 Hz continued in 980 Hz.

So, the difference is that the start bit is 9.1 ms in one case, and the
start bit plus two data bits are 10 ms in the other case. Is this enough to
decide on 110 or 300 bps and time the detector to generate bit events during
the row of bits in steady 980 Hz?

Is there a need for also a detector specification?

Gunnar

---

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

Where is this stuff specified?  I can't find any sign of it in V.21 itself.

Gunnar Hellstrom wrote:

>>this question, maybe it is totally out of scope that a textphone call
> 
> needs
> 
>>require implementations to be able to handle events spanning multiple
> 
> bits?
> 
>>Tom Taylor
>>
>>

---

From: Tom Taylor <[email-masked]>
Date: Thu, 13 Nov 2003 22:27:42 -0600

Actually, I'm not sure this is relevant to 2833bis.  2833bis starts with 
the assumption that the sender recognizes the event.  You're saying that 
a sender able to distinguish between 110 bits/s and 300 bits/s V.21 will 
be tough to build.  2833bis isn't specifying a universal gateway, just 
giving gateways a language.

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Thu, 13 Nov 2003 22:49:00 -0600

The trick is that usually V.21 users have agreed before the call, what
bitrate they will use.
If a Swiss textphone user calls another, they both have V.21s running at 110
bps.

So, then the modems trig on the start bit edge, and clock out its bits and
sample the frequency in the middle of the bits.

I guess that there are some words about that in V.21. Something about
pre-agreed bitrate or so.

But if you are designing a more general detector that has the ambition to
detect and transmit all tone signals reliably, then you end up in the kind
of tricky determination situations I mentioned.

We already have it in the text telephone auto moding modem V.18, that also
need to detect and discriminate between these quite close alternatives.

Gunnar

---

From: Tom Taylor <[email-masked]>
Date: Tue, 18 Nov 2003 09:50:39 -0500

I've had a couple of after-thoughts on your note.

First: as far as I know, RFC 2833 does not pretend to cover V.21s, as 
opposed to V.21.  As I understand it, the scope of 2833 is limited to 
session setup, not content once a session is started.  For that you use 
G.711 or V.150.1 modem relay or perhaps CLEARMODE.

Secondly, aren't your timings out by an order of magnitude?  At 300 
bits/s, surely each bit event can't take more than 3.3 ms.

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Tue, 18 Nov 2003 10:17:23 -0600

Tom,
You are probably right, it would be a waste of bandwidth to send V.21
session data as RFC2833 signals.
For V.21 session data in the text telephone case that I am thinking of,
RFC2793 is to prefer.

However, for DTMF, I think you should have detectors for RFC2833 on during
the whole voice call, not just during session setup.

What is V.21s?

The timings are right.
At 300 bits/s the bits are 3.3 ms. At 110 ms it is 9.1 ms.
The tricky example was to distinguish between a character at 300 bits/s
starting with start bit and two 0-bits giving a 9.9 ms long single tone,
then followed by 6 1-bits, a stop bit and then line fill with steady 1.
That will give the pattern of 9.9 ms of 1180 HZ followed by endless 980 Hz.
The comparison was with a byte of FF in 110 bits/s V.21 that is 9.1 ms of
1180 Hz, followed by endless 980 Hz.

If we follow the original idea, not to use RFC2833 for text telephony text,
it may be OK to limit the support to 300 bits/s V.21. All the session
startup examples of use of v.21 are using 300 bits/s.

Gunnar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Tom
Taylor
Sent: Tuesday, November 18, 2003 8:51 AM
To: Gunnar Hellstrom
Cc: [email-masked]
Subject: Re: SV: SV: [AVT] More on V.21 events

---

From: Tom Taylor <[email-masked]>
Date: Tue, 18 Nov 2003 11:32:32 -0500

Ah, now I understand -- you were talking bytes where I was thinking 
bits.  It happens that V.21 uses F-subscript-A to designate the higher 
characteristic frequency (binary 0) of a channel.  So I thought you were 
talking bits.

Gunnar Hellstrom wrote:

>>E.g. the 300 bps byte FA versus the 110 bit/s byte FF are quite close. (
> 
> if
> 
>>I get bit-order right )
>>
>>The 300 bps byte FA in V.21 lower channel is 980 Hz lead-in, 10 ms  of
> 
> 1180
> 
>>The 110 bps byte FF in lower channel V.21 is 980 Hz lead-in, 9.1 ms of
> 
> 1180
> 
>>start bit plus two data bits are 10 ms in the other case. Is this enough
> 
> to
> 
>>decide on 110 or 300 bps and time the detector to generate bit events
> 
> during
> 
>>original question still stands, but is perhaps less pressing at lower
> 
> rates.
>