Subject: RE: [AVT] 2833bis - V.21

From: "Miao, Kai" <[email-masked]>
Date: Tue, 5 Nov 2002 10:31:25 -0500

Why not carry multple event "frames" in one RTP packet, as in multiple codec
frames per packet format for voice, to pack multiple v.21 bits into one
packet? Signaling for this should be same as for voice. It seems to be a
cleaner solution. 

Also, this is not in conflict with using volume field to carry that 6 bits,
but only enhancing it. And, RFC2198 does not seemed to have been created for
carry concurrent bits.

Kai

-----Original Message-----
From: Flemming Andreasen [mailto:[email-masked]]
Sent: Wednesday, October 23, 2002 1:22 PM
To: Henning Schulzrinne
Cc: [email-masked]
Subject: Re: [AVT] 2833bis - V.21

Henning Schulzrinne wrote:

> > - V.21 data bits:  It would be nice if we had a more efficient way of
> > sending
> > V.21 data bits which also doesn't require us to use RFC 2198
> > redundancy. We
> > could for example define two new events (one for each V.21 channel)
> > that simply
> > use the (otherwise unused) volume field to encode the actual bit
> > values. That
> > would enable us to send 20 ms of V.21 data bits in a single event.
> > Alternatively, we could consider encoding it in the duration field as
well
> > (e.g. have volume indicate number of bits and duration the actual
> > bits), but
> > that seems more inconsistent (it would on the other hand allow us to
> > encode up
> > to the recommended 50 ms).
>
> I'd rather not mess with the duration field, since that seems to
> possibly break things and requires more special-casing. I added the
> first option. Also, you need the duration to indicate which bits are
> actually valid. Otherwise, how would you express 0101, say?
>

You could special-case everything but I agree that the first option is
preferable.

Nit:    Both entries in Table 3 for V.21 compressed say "channel 1". One of
them
should say "channel 2".

-- Flemming

_______________________________________________
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

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 07 Nov 2002 13:52:37 -0500

Seems like a reasonable idea to me, but I think you would need to tinker a
little with the definition of the "duration" field first (since it refers to the
RTP timestamp). Backwards compatibility with RFC 2833 could be an issue though.

-- Flemming

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 07 Nov 2002 14:39:24 -0500

I suspect that multiple frames in one packet would only be feasible for 
V.21 and similar data events that are contiguous. There are three 
possible approaches, I think:

- "it's too late to change" - tell people to use 2198

- "nobody has implemented it yet" - don't worry about backward compatibility

- "new events" - if this is indeed limited to V.21 or similar, we would 
define this behavior only for new events added after 2833.

A more basic question is whether this is a common enough problem to 
worry about it.

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 07 Nov 2002 15:00:32 -0500

> - "it's too late to change" - tell people to use 2198

Clearly works.

> - "nobody has implemented it yet" - don't worry about backward compatibility

Not a good idea IMO.

> define this behavior only for new events added after 2833.

A reasonable option too.

> A more basic question is whether this is a common enough problem to

Personally, I'm fine with being able to send up to 20 ms V.21 in a single 2833bis
event, and then have to use 2198 if I wanted to send less frequently.

-- Flemming