Satish,
I am sending you this mail and also to the
other AVT members.
I want to make it VERY clear how and what
goes on with text/t140 and audio/t140.
I am worried about the delays and
difficulties about RFC2793 bis.
It is my opinion that this draft (-04
version) is ready for the RFC track.
First, Interactive text (140/RTP as
described in RFC2793) MUST be for all users as text/t140. That is the main use.
Audio/t140 is ONLY for the benefit of
large PSTN trunking gateways that are processing thousands of calls. By
transporting text as audio/t140, then the GW can switch between voice and text,
just as it switches between voice and RFC 2833 DTMF relay.
I am
quoting Paul Jones here:
For the sake of getting things done, it
would be easier to "switch" over the same RTP port based on the media
type. There is actually a lot of overhead in every port we support (all the
way from the DSP up to the session protocol-- T.38 over UDP has been somewhat
of a pain, so we now have T.38 over RTP, too). Here is some of the rationale:
* Fewer ports = less memory and
processing. This really adds up
on the larger 10,000 port gateways,
the number of ports for
audio RTP/RTP + T.38 RTP + text
RTP/RTCP would be
50,000. Worse, only 20,000 ports are
actually used at any
given time. Managing 50,000 ports
does add significantly to
the processing demands on the box.
* Signaling is significantly
simplified-- one opens a single
RTP session. In SDP, the
"m=" line will contain the
list of codecs (including
audio/t140). In H.245, an OLC
will use the
"multiplePayloadStream" data type to accomplish
the same thing.
* Using the same port and, therefore the
same clock,
eases synchronization of audio and
text over the PSTN.
* The counter argument: what benefit is
there with using
a separate port? On a PSTN GW,
everything is transmitted
over a PSTN circuit. What is the
rationale for extracting
voice and sending it over one session,
text over another,
T.38 over a third, etc. There is no
value in doing that
from a PSTN gateway perspective-- it
simply adds to the
complexity with no net gain.
By their
very nature, a PSTN GW cannot have simultaneous media-- though it can multiplex
So, audio/t140 is PSTN gateway ONLY! And
between PSTN gateways ONLY and not any possibility for end-user agent to the
gateway!
It is also NOT meant as a way to transport
analog text telephone tones (e.g. Boudot or DTMF) over IP!
Sending analog text telephony over IP is
and will be a bad idea.
An important requirement in RFC3351:
Transcoding services and User Agents MUST be able to connect with
each other regardless of the provider or manufacturer. This means
that new User Agents MUST be able to support legacy protocols through
appropriate gateways
To ensure that all interactive text will
connect without any problem:
Text/t140 is default for all Useragents.
Thus end-user connects text using RFC
2793, text/t140 with each other. Also theText gateways and PSTNs must only
accept text/t140 from the end-UAs.
Gateway-gateway (PSTN or any other text
gateway) MUST accept and understand text/t140. In some cases audio/t140 is
preferred, this only between PSTNs for the reasons quoted above!
Can we get a consensus from the AVT group
that text telephony MUST be done via text/t140 as described in RFC2793bis-04,
and that backward compatibility with analog textphones (legacy textphone
protocols) is ONLY through gateways? And that audio/t140 is only for PSTN
trunking and not to be abused to slip any legacy textphone protocol through it?
Greetz
Arnoud
From:
avt-admin at ietf.org [mailto:avt-admin at ietf.org] On Behalf Of Mundra, Satish
Sent: zaterdag 15 mei 2004 0:19
To: 'Arnoud van Wijk'; 'Gunnar
Hellstrom'; 'Paul E. Jones'; 'avt IETF'
Subject: RE: [avt]
Comments/questions on draft-ietf-avt-rfc2793bis-04
Arnoud,
Here is
brief summary in response to your question on the Mbit, and you can refer to
comments on draft-03 for other
issues.
For audio
encodings, M-bit can be used for making playout delay adjustments at the
beginning of talkspurt. Most video encoding set it on the last packet of a
video frame to signal the end of frame. For text encoding no behavior is
specified.
Encoding
audio/t140 is one more voice encoding and hence should follow the
behavior specified in
RFC3551. One certainly can not depend on the M-bit being present
and hence must be robust if the
packet is lost, however, there are implementation that
would improve playout
performance/behave differently when the packet with M-bit is not lost.
2793bis-04
defines zero-length packets for use during "silence periods" but
different rules govern their re-transmission when redundancy is used depending
on whether audio/t140 or text/t140 is used. At times those MUST requirements
can not be satisfied for e.g., when the "Silence Period" is longer
than 16383/clock-rate.
The last
one is not an issue but an observation. There is two byte sequence number in
audio/t140 payload that is in sync with RTP sequence number during a text-spurt
and the reason for different rules above. The primary use for the counter in
the payload is, as I
understand
it, to distinguish between loss of audio/t140 data and voice data so that text
loss can be indicated to user when 2198 is used. We were discussing
if the M-bit could
allow one
to do the same instead of counter. The authors feel that it is needed to mark
the
missing text accurately and this is
fine.
Regards,
Satish
Mundra
>
-----Original Message-----
> From: Arnoud van Wijk [mailto:a.vwijk at viataal.nl]
> Sent: Friday, May 14, 2004
8:46 AM
> To: 'Mundra, Satish'; 'Gunnar
Hellstrom'; 'Paul E. Jones'; 'avt IETF'
> Subject: RE: [avt]
Comments/questions on draft-ietf-avt-rfc2793bis-04
>
>
> I am trying to follow what the
big deal is about the M-bit. In my
> opinion the draft
rfc2793bis-04 is finished and ready to work.
>
> What am I then missing?
>
> 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
>
> -----Original Message-----
> From: avt-admin at ietf.org [mailto:avt-admin at ietf.org] On
> Behalf Of Mundra, Satish
> Sent: woensdag 12 mei 2004
21:11
> To: 'Gunnar Hellstrom'; Paul
E. Jones; avt IETF
> Subject: RE: [avt]
Comments/questions on draft-ietf-avt-rfc2793bis-04
>
> Gunnar,
>
> responses inline...
>
> > -----Original
Message-----
> > From: Gunnar Hellstrom [mailto:gunnar.hellstrom at omnitor.se]
> > Sent: Tuesday, May 11,
2004 6:32 PM
> > To: Mundra, Satish; Paul
E. Jones; avt IETF
> > Subject: RE: [avt]
Comments/questions on
> draft-ietf-avt-rfc2793bis-04
> >
> >
> > Satish,
> > I get the impression that
your main goal with the
> discussion is to try
> > to find a format for
audio/red/t140 that could allow us to drop the
> > t140block counter from
the format.
> >
> > Is the reason saving
bits?
> >
>
> Yes, saving six bytes per
audio/red/t140 packet could buy one
> more level of redundancy
> if needed.
> If you feel that it's required
for reliable operations, and
> change at this stage is not
desirable, that's fine with me.
>
> > We have had it there
since August, with no major concerns,
> so it seems
> > acceptable to most reviewers.
> >
> > You also want to use the
M-bit as in RFC3551.
> > > The M-bit behavior
is from (RFC3551): "For applications
> which send
> > > either no packets or
occasional comfort-noise packets
> > during silence,
> > > the first packet
> > > of a talkspurt, that
is, the first packet after a silence
> > period during
> > > which packets have
not been transmitted contiguously, SHOULD be
> > > distinguished by
setting the marker bit in the RTP data
> > header to one."
> > That can be OK. But then
you must not do anything drastic, such as
> > adding a missing text
marker just because the packet with the M-bit
> > seems to be missing. With
10% packet loss, 10% of the
> M-bits will be
> > missing, but only 0.1% of
text, if we are using primary and two
> > redundant transmissions.
> >
>
> One need not solely depend on
the missing primary with marker
> to conclude loss of
> t140 data for audio/red/t140.
>
> Assuming that 10% of M-bits
are lost:
> If the total number of
consecutive packets lost is less than
> the redundancy level in use,
one can easily determine if the
> missing sequence numbers were
carrying text or voice.
> At other times I agree that it
may not be obvious. It seems
> like one could use both the
timestamp gap and sequence number
> gap to determine if any text
was lost. Note that
> when text is transmitted the
sequence numbers increments by 1
> every 300/500ms where
> as for voice it would be every
20/30ms or so.
>
>
>
>
>
> > Would it be OK to you to
take in the text about the M-bit from
> > RFC3551?
> >
>
> Yes.
>
>
> Thanks,
>
> --Satish
>
>
>
>
> > Gunnar
> >
> >
> >
-------------------------------------------
> > Gunnar Hellström
> > Omnitor AB
> > Renathvägen 2
> > SE 121 37 Johanneshov
> > SWEDEN
> > +46 8 556 002 03
> > Mob: +46 708 204 288
> > www.omnitor.se
> >
Gunnar.Hellstrom at Omnitor.se
> >
--------------------------------------------
> >
> >
> > > -----Original
Message-----
> > > From: avt-admin at ietf.org
[mailto:avt-admin at ietf.org]On Behalf Of
> > > Mundra, Satish
> > > Sent: Tuesday, May
11, 2004 7:19 PM
> > > To: 'Gunnar
Hellstrom'; Paul E. Jones; avt IETF
> > > Subject: RE: [avt]
Comments/questions on
> >
draft-ietf-avt-rfc2793bis-04
> > >
> > >
> > > Gunnar/Paul,
> > >
> > > Thanks for
summarizing the questions. The previous comments got
> > > cross-posted, I have
used your latest posting for further
> debate on
> > > the
questions/comments. See comments inline...
> > >
> > > Regards,
> > >
> > > Satish Mundra
> > >
> > > > -----Original
Message-----
> > > > From: Gunnar
Hellstrom [mailto:gunnar.hellstrom at omnitor.se]
> > > > Sent: Monday,
May 10, 2004 6:29 PM
> > > > To: Paul E.
Jones; Mundra, Satish; avt IETF
> > > > Subject: RE:
[avt] Comments/questions on
> > > >
draft-ietf-avt-rfc2793bis-04
> > > >
> > > >
> > > > Satish,
> > > > I am eager to
come to conclusions on your questions regarding
> > > >
draft-ietf-avt-rfc2793bis-04.
> > > >
> > > > Our (Paul´s and
mine ) understanding regarding the
> questions are
> > > > now:
> > > >
> > > > 1. Security
risk to have the 16-bit T140block counter to always
> > > > start at 0 in a
session. I mentioned that loss in the beginning
> > > > could be
detected by the text stream not starting with
> > the Unicode
> > > > synchronization
character, because the requirement to
> start with
> > > > that code is
clearly stated in T.140. So, that could be
> > used and the
> > > > counter could
then start at a random value. However, also this
> > > > session start
code can be seen as a security risk with the same
> > > > reason as the 0
counter would be one. Are not all media full of
> > > > predictable bit
patterns, like picture start headers, audio
> > > > session
parameters etc?
> > > >
> > > > We would like
to hear more voices if it is important to
> start the
> > > > counter at a
random value, and instead rely on detection
> > of initial
> > > > loss by a
missing Unicode Synchronization character.
> > > >
> > >
> > > See comments on the
"t140block counter" below.
> > >
> > > > 2. M-bit for
indication of start of text.
> > > > You hint that
we should specify that the M-bit SHALL be used as
> > > > indicated in
the AVT profile for indicating start of text
> > initially
> > > > in the stream
and also after a gap. This could be used both to
> > > > detect loss and
in order to detect when suspected loss is
> > only loss
> > > > of empty text
blocks.
> > > >
> > >
> > > Yes.
> > >
> > > > Each M-bit is
only sent once, so it does not get improved
> > > > reliability by
redundancy. We have a mechanism with
> > marking missing
> > > > text with a
Unicode replacement character, specified in
> > T.140. If in
> > > > doubt, it is
better to mark too much than too little,
> > because there
> > > > will be
non-printable characters that will be marked by this
> > > > character when
lost. Therefore the users might know that
> > there can
> > > > be markers for
missing text without any visible text missing.
> > > >
> > >
> > > Let me understand
this again, the requirement for the
> > payload format
> > > is to NOT fail in
detecting LOSS when occurs, misleading loss
> > > indicators are
unavoidable and seem to be acceptable.
> [see further
> > > comments on the
block counter below]
> > >
> > > > So, for
audio/t140, we can select between three methods for
> > > > indicating the
start of stream: a. counter =0 b. M-bit
> > c. Unicode
> > > > start of stream
character
> > > >
> > >
> > > See comments on
counter below.
> > >
> > > > For text/t140,
we can only select between two methods: a. M-bit
> > > > b.
Unicode start of stream character
> > > >
> > > > A missing M-bit
does not give full information if a real text
> > > > element is
missing. The text might be received in
> > redundant code.
> > > > But it can be
used as a likely indication.
> > > >
> > > > The other
methods are at least as reliable as the redundant
> > > > transmission
method used.
> > > >
> > > >
> > > > For text during
a session, we have the following problem:
> > What is a
> > > > gap? When shall
the M-bit be set to 1? What is a text-spurt?
> > > >
> > >
> > > Borrowing from
section 5.4 of draft(04), gap would be "no
> new T.140
> > > data to transmit
after the transmit buffering interval
> described in
> > > section 5.1 has
> > > passed".
This defines the text-spurt which is analogous to
> > talkspurt.
> > >
> > > The M-bit behavior
is from (RFC3551): "For applications
> which send
> > > either no packets or
occasional comfort-noise packets
> > during silence,
> > > the first packet
> > > of a talkspurt, that
is, the first packet after a silence
> > period during
> > > which packets have
not been transmitted contiguously, SHOULD be
> > > distinguished by
setting the marker bit in the RTP data
> > header to one."
> > >
> > > > For text/t140,
it is hard to find a good delimitation
> for when a
> > > > text-spurt
starts. There is no declaration of the time
> > between the
> > > > packets, just
the buffering time that normally may be
> 300 ms, but
> > > > may vary. For
the text/red/t140 case, there could be a
> > reason to use
> > > > the M-bit, when
only the primary data contains valid
> > text. The other
> > > > blocks should
be empty or non-existing. That is the
> case after a
> > > > pause.
Detection of an M-bit can make sure that the risk
> > is kept low
> > > > for falsely
marking loss of data during the pause. Without the
> > > > use of the
M-bit, falsely marking lost text will occur slightly
> > > > more often.
> > > >
> > >
> > > The text-spurt
starts with the packet that you transmit after a
> > > zero-length block is
transmitted, that happens whenever the T.140
> > > buffering interval
expires and no new data
> > > is available for
transmission.
> > >
> > >
> > > > For the plain
text/t140 format, I do not see any need
> for marking
> > > > the first
packet after a longer pause.
> > > >
> > >
> > > It helps in
situations when one can not include a
> > zero-length block as
> > > redundant data
because it's too old.
> > >
> > > > For
red/audio/t140 I see no need for the M-bit. The
> > counter give a
> > > > better
reliability.
> > > >
> > >
> > > During a interval
where text is transmitted contiguously, the
> > > block-counter and
the RTP sequence numbers are in sync. So
> > I guess the
> > > counter is only
useful at the boundaries when
> > > switchover between
voice/text payload is occurring. Under
> > certain loss
> > > scenarios or when
both marker and zero-length blocks are lost one
> > > could have
misleading text loss-indicator which in any case are
> > > unavoidable. In
either
> > > case you would
detect loss as required.
> > >
> > > As I mentioned
earlier, I am unconvinced about the
> > usefulness of the
> > > block counter.
During contiguous text transmission the
> > counter and RTP
> > > sequence numbers are
in sync. Even if marker is lost, one
> > could sync
> > > to the first
sequence number that can be deriver or is
> > present in the
> > > header. IMO,
different redundancy rules for text/t140 and
> > audio/t140
> > > can be unified and
> > > implementation
simplified.
> > >
> > > > The current
RFC2793 does not specify the use of the M-bit.
> > > > RFC2793bis
should be compatible with RFC2793 for text/t140 and
> > > > text/red/t140.
Using the M-bit for RFC2793 bis would be a
> > step off
> > > > from that
direction.
> > > >
> > > > Anyway, it does
little harm, so if there are voices for
> > it, we could
> > > > say that the
transmitter MUST use the M-bit to indicate
> start of
> > > > stream, and
start after a pause. The receiver MAY use it for
> > > > detection of
loss.
> > > >
> > > >
> > > > Please advice
> > > >
> > > > Regards
> > > >
> > > > Gunnar
> > > >
--------------------------------------------------------------
> > > > -------------
> > > > -------
> > > >
> > > >
> > > > Satish,
> > > > Further answers
inline,
> > > >
> > > > Gunnar
> > > >
> > > >
-------------------------------------------
> > > > Gunnar
Hellström
> > > > Omnitor AB
> > > > Renathvägen 2
> > > > SE 121 37
Johanneshov
> > > > SWEDEN
> > > > +46 8 556 002
03
> > > > Mob: +46 708
204 288
> > > > www.omnitor.se
> > > >
Gunnar.Hellstrom at Omnitor.se
> > > >
--------------------------------------------
> > > >
> > > >
> > > > >
-----Original Message-----
> > > > > From: Paul
E. Jones [mailto:paulej at packetizer.com]
> > > > > Sent:
Thursday, May 06, 2004 11:10 PM
> > > > > To:
Mundra, Satish; 'Gunnar Hellstrom'; avt IETF
> > > > > Subject:
Re: [avt] Comments/questions on
> > > > >
draft-ietf-avt-rfc2793bis-03/04
> > > > >
> > > > >
> > >
> > > X--------snip
> > >
> > >
_______________________________________________
> > > Audio/Video
Transport Working Group
> > > avt at ietf.org
> > > https://www1.ietf.org/mailman/listinfo/avt
> > >
> > >
> >
> >
>
>
_______________________________________________
> Audio/Video Transport Working
Group
> avt at ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
>
>
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt