Subject: RE: [avt] Comments/questions on draft-ietf-avt-rfc2793bis-04

From: "Mundra, Satish" <[email-masked]>
Date: Fri, 14 May 2004 18:19:29 -0400

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:[email-masked]]

> 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: [email-masked] [mailto:[email-masked]] 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:[email-masked]]

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

> > [email-masked]

> > --------------------------------------------

> > > -----Original Message-----

> > > From: [email-masked] [mailto:[email-masked]]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:[email-masked]]

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

> > > > [email-masked]

> > > > --------------------------------------------

> > > > > -----Original Message-----

> > > > > From: Paul E. Jones [mailto:[email-masked]]

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

> > > [email-masked]

> > > https://www1.ietf.org/mailman/listinfo/avt

> _______________________________________________

> Audio/Video Transport Working Group

> [email-masked]

> https://www1.ietf.org/mailman/listinfo/avt

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