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

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 2 Dec 2003 11:56:36 -0500

Arnoud,

RFC 2833 can be used to convey tone information (frequencies and durations),
as well as tone events.  It's not restricted to DTMF.

RFC 2833 could potentially be used as an alternative to RFC 2793.  A gateway
or IP phone, for example, could simply examine the tones and convey those as
"descriptions" (either frequency and duration information or event codes)
over an IP network.  The other end could then receive those descriptions and
reproduce the tones.  They would not have to understand the underlying
textphone protocol.

The problem with RFC 2833, as I see it, is that it stands at odds with the
desire of folks on the ToIP mailing list to try to remove textphone
signaling from the IP network.  There has been a strong desire expressed to
terminate that textphone signaling at the gateway and only use text on the
IP network.  Doing that, arguably, would make interfacing with IP-based IVR
systems, IP-based voice/text-mail systems, or other IP-based systems much
easier.  I say "arguably" because some have suggested to me that it's very
simple to write software that understand the textphone signals received in
RFC 2833 packets... though I personally think it puts an unfortunate burden
on a Pocket PC, for example.

To this point, neither the ITU nor the IETF has considered RFC 2833 as an
option or alternative to RFC 2793.  I think this is probably an important
topic that we should take up immediately, as both bodies are forging ahead
with plans based on RFC 2793 only.

Paul

----- Original Message ----- 
From: "A vWijk" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Tuesday, December 02, 2003 7:45 AM
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: Tom Taylor <[email-masked]>
Date: Wed, 03 Dec 2003 10:57:43 -0500

The existing events in 2833 have to do primarily with startup.  I have 
to ask how the TOIP people see startup negotiation working without 2833 
support.  You still have to deal with V.8 or V.8bis in the more advanced 
terminals.

There is the fact that two V.18 terminals in conversation phase use 
V.21, and V.21 events are included in the 2833 repertoire.  This means 
that telephone events could be used during conversation phase in some 
cases.  However, the basic discussion is over the set of events needed 
to achieve transition to conversation phase successfully.

Turning to the conversational phase, I do not see how the use of RFC 
2793 between gateways in place of the various alternatives (G.711 VBD, 
V.150.1 modem relay, the tones payload type, V.21 or other events) will 
affect the user experience.  I assume the reason this is desired is to 
simplify the transition to packet-mode terminals.

The problem here is that gateways have to handle a wide variety of 
traffic, not just text.  This makes more generic approaches like V.150.1 
for voice-band data simpler to implement, so I see some vendors making 
that choice.  Obviously, if packet terminals require RFC 2793 and 
gateways cannot handle it, deployment of these gateways is limited to 
bridging of PSTN segments.  Given that this application still represents 
a substantial market segment, we should probably add the 2833 events 
needed to handle it properly.

---

From: Tom Taylor <[email-masked]>
Date: Wed, 03 Dec 2003 13:19:54 -0500

OK, so in North America the gateway always emulates a Baudot terminal. 
That means it won't be possible to negotiate alternating text and voice 
with a V.18 terminal.  I imagine Gunnar's bitter response to that one is 
that nobody is making V.18 terminals anyway.

Arnoud van Wijk wrote:

> I think the question we need answered is:
> " Do we need to transport real-timing streaming text (aka Interactive Text)
> through PSTNs with RFC 2833 (a beefed up version of it)?"
> 
> For Interactive Texting, gateways it will be necessary to allow backward
> compatibility with analogue textphones. Transcoding from T.140/RTP into the
> local legacy textphone protocol. For America it is then Boudot.
> All that the gateway has to do is simply connect to a PSTN using Boudot over
> the voice channel. Every PSTN connects with an Interactive Text gateway. And
> that IT gateway does the transcoding, so that the PSTN sees it as a voice
> channel as it is done today.
> 
> There is then no RFC 2833 involved for the Interactive Texting.
> 
> Thus when we get 2 PSTN's that are linked together over IP for a voice call,
> then is it much easier to send the text as RFC 2793.
> So, the only requirement is then that every PSTN must have a means to
> transcode RFC 2793 into local analogue text telephony (directly or via an IT
> gateway).
> 
> I want to have clarity on this before starting to complicate matters even
> more. Analogue text telephony is a dying beast. And my goal is to kill it as
> fast as possible without any problems.
> 
> Greetz
> 
> Arnoud
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 3 Dec 2003 16:01:52 -0500

Tom,

I don't think we can say that North American GWs only speak Baudot.  We must
allow a V.21 user to call home to England, for example.  Your point about
the use of RFC 2833 for start-up messages is valid and is likely to occur
between two gateways, as they would have negotiated the use of certain RFC
2833 tones and event messages.  Such description falls into the scope of
ITU-T V.ToIP.

However, if a gateway happened to terminate to a Pocket PC, for example, no
such tones would be negotiated or used.  The gateway could either "eat"
those tones or assume it's a textphone device.  The behavior needs to be
specified somewhere... perhaps also in V.ToIP?

In any case, I think we're in agreement that RFC 2833 should not be used as
a text transport mechanism.  It might be used as part of start-up exchanges
before it can be determined that the calling/called device is a modem, fax,
or TTY device.  GW-GW calls have slightly special requirements that IP
phones do not have.

Paul

----- Original Message ----- 
From: "Tom Taylor" <[email-masked]>
To: "Arnoud van Wijk" <[email-masked]>
Cc: "'Paul E. Jones'" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, December 03, 2003 1:19 PM
Subject: Re: Betr.: FW: [AVT] Missing events in RFC 2833

---

From: "Arnoud van Wijk" <[email-masked]>
Date: Wed, 3 Dec 2003 17:48:23 +0100

Greetz

Arnoud

-----Original Message-----
From: Tom Taylor [mailto:[email-masked]] 
Sent: woensdag 3 december 2003 16:58
To: Paul E. Jones
Cc: A vWijk; [email-masked]; [email-masked]; [email-masked];
[email-masked]

---

From: Tom Taylor <[email-masked]>
Date: Thu, 04 Dec 2003 10:19:52 -0500

Based on this intervention, I would propose to add the list of events 
given by Gunnar to those already given in RFC 2833.

Paul E. Jones wrote:

>>>" Do we need to transport real-timing streaming text (aka Interactive
> 
> Text)
> 
>>>compatibility with analogue textphones. Transcoding from T.140/RTP into
> 
> the
> 
>>>All that the gateway has to do is simply connect to a PSTN using Boudot
> 
> over
> 
>>>the voice channel. Every PSTN connects with an Interactive Text gateway.
> 
> And
> 
>>>that IT gateway does the transcoding, so that the PSTN sees it as a
> 
> voice
> 
>>>Thus when we get 2 PSTN's that are linked together over IP for a voice
> 
> call,
> 
>>>transcode RFC 2793 into local analogue text telephony (directly or via
> 
> an IT
> 
>>>gateway).
>>>
>>>I want to have clarity on this before starting to complicate matters
> 
> even
> 
>>>more. Analogue text telephony is a dying beast. And my goal is to kill
> 
> it as
>