Subject: RE: Betr.: FW: [AVT] Missing events in RFC 2833

From: "Gunnar Hellstrom" <[email-masked]>
Date: Tue, 2 Dec 2003 20:47:36 +0100

Arnoud and all,

I do not think it is desirable to try to patch up RFC2833 to transport all
kinds of textphone data events. In my view it is likely to be complex,
unreliable and against the efforts to create mainstream conversational
services for all with high functionality in the IP network.

But I wanted to expose this question from Tom to the text conversation
interested people to get your view, and give som good advice back to Tom,
who is just now cleaning up RFC2833.

You are rtight that RFC2833 started as a mechanism for DTMF transport and
that is what it is most famous for. But have a look in it, and you will find
that many other signals that are likely to appear in PSTN connections can be
coded with RFC2833.

If we had any wish to recreate the same tones at exit as was input, there
could be a case for patching up RFC2833 to (detect and) transport all
textphone data properly.

Now, the case is the opposite, we want to disconnect the technologies in the
both ends as much as possible, and have a pure text code in between.
Therefore, complete V.18 in the PSTN edge and RFC2793 transport is the
solution I see have a future.

Agree?

Gunnar
-------------------------------------------
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]
--------------------------------------------

-----Original Message-----
From: A vWijk [mailto:[email-masked]]
Sent: Tuesday, December 02, 2003 1:45 PM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Betr.: FW: [AVT] Missing events in RFC 2833

Gunnar,
why is this desirable?

We will have T.140 over RTP and in some cases over TCP/IP.
Why the tones?

Or am I mixing things up again? RFC2833 is for DTMF signalling?

greetz

Arnoud

Drs. Arnoud A. T. van Wijk
Viataal
Research & Development
Afdeling RDS
Theerestraat 42
5271 GD Sint-Michielsgestel
The Netherlands.
Mobile: +31651921948
International text telephone: +31735588408

>>> "Gunnar Hellstrom" <[email-masked]> 01-12-03 23:20 >>>
Below, Tom Taylor asks if there is any interest to complete the textphone
related tone events in RFC2833 so that all V.18 submodes can be transported
with RFC2833.

We have to verify that we have satisfying detection and transport methods in
RFC2793, and e.g. V.18 or the H.248.2 package descriptions, so that we can
leave RFC2833 half done for text transport.

I would like to do so, but then the market forces must be strong enough to
make RFC2793 and textphone detection commonplace.

Using RFC2833 will place a task similar to V.18 logic on the IP endpoint,
but with less exact information than the native V.18 has. We have no
analysis if that task is realistic, nor if it is likely to be implemented by
IP endpoint developers.

( The missing events for complete text transport are probably:
V.21 data in lo channel at 110 bits/s
Bell 103 hi channel data at 300 bits/s
Bell 103 lo channel data at 300 bits/s
V.23 data at 1200 bits/s
V.23 data at 75 bits/s
Baudot data at 45.45 bits/s
Baudot data at 50 bits/s

(assuming that V.8 signals and V.21 at 300 bits/s in both directions and
DTMF are covered )

Gunnar

-------------------------------------------
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]
--------------------------------------------

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Tom
Taylor
Sent: Monday, December 01, 2003 5:37 PM
To: [email-masked]
Subject: [AVT] Missing events in RFC 2833

I'm finding it a little difficult to see how some of the applications
supported by RFC 2833 work without a few more events.  Here are some
examples:

1. V.18 text telephones interwork with a number of other text telephone
types.  The only event defined specifically for V.18 operation seems
rather arbitrarily chosen: the ANS2225 event for Bell 103 answer tone.
There don't seem to be any events for Baudot or V.23 or for Bell 103 in
calling mode.

2. Signalling System No. 5 has two sets of signals: line signals, which
are tones controlling trunk state, and register signals, which convey
digits with some supporting information.  There is a timing constraint
that register signalling must begin within 80 +/- 20 ms of the end of
the "seize" line signal.  Yet no event is defined for "seize", only for
the register signals.  It's a little hard to see how the receiving
gateway can propagate KPx (the initial register signal) on time if it
doesn't know that "seize" was playing, even if the sending end can
recognize and report the start of KPx within the 20 ms tolerance.  As I
see it, the present set of events is useful only to transfer the
register events from one gateway to another which will report them to
call control rather than propagating them as tones.

These missing events raise the issue of whether proposals to add events
to RFC 2833 should be backed up by requirements documents describing
their use.  I have been adding brief application descriptions in my
rewrite of 2833bis, as justification for the normative text which I have
also been adding.  (Basically just obvious stuff, missing the first time
around and highlighted by Flemming's comments earlier this year.)  I am
hoping that this additional information prompts a critical review of the
current set of 2833/2833bis events, with a view to rounding them out as
necessary to make applications work well.

Tom Taylor

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

-
This list is maintained by Snowshore Networks - http://www.snowshore.com
All comments on this list are the comments of the message originators and
Snowshore is not to be held responsible for any actions or comments found
on this list. The archives for this list can be found at
http://flyingfox.snowshore.com/toip_archive/maillist.html

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

---

From: "Arnoud van Wijk" <[email-masked]>
Date: Tue, 2 Dec 2003 23:59:49 +0100

Hello Gunnar,
Yes. I agree.

I will give RFC 2833 a read to see what has been changed.
And we should make it clear that RFC 2833 will not mention text telephony
except: " For text telephony, please read RFC 2793 and the Text over IP
draft (RFC # something in the future)". Or something like that.

Greetz

Arnoud

-----Original Message-----
From: Gunnar Hellstrom [mailto:[email-masked]] 
Sent: dinsdag 2 december 2003 20:48
To: A vWijk; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: Betr.: FW: [AVT] Missing events in RFC 2833

Arnoud and all,

Agree?

Gunnar

-----Original Message-----
From: A vWijk [mailto:[email-masked]]
Sent: Tuesday, December 02, 2003 1:45 PM
To: [email-masked]; [email-masked]; [email-masked];

Gunnar,
why is this desirable?

greetz

Arnoud

Gunnar

-----Original Message-----

Tom Taylor

-

---

From: Tom Taylor <[email-masked]>
Date: Wed, 03 Dec 2003 08:51:41 -0500

Does this mean you also deprecate any use of V.150.1 for carrying text 
telephony?