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

From: "Miao, Kai" <[email-masked]>
Date: Thu, 7 Nov 2002 17:24:22 -0500

With an event packet rate running at 50ms, I would need to pack 15 (6+6+3)
bits into 2.5 "volume fields", i.e., three 2833 event frames. These three
frames would have to be treated as one single event that goes into one 2198
packet with a block size 12. So, the primary part in this 2198 packet looks
much like "multiple frames in one packet" to me. So, I think we already have
multiple frames in one packet using v21 compressed format and 2198. 

Unless we forget about redundancy altogether for 2198 packets and treat them
as "flat" bit packets.....Then, we would NOT be able to use redundancy when
it is most needed, for carrying DATA. 

The above should not be regarded as an arguement for "multiple frames per
packet".......

Ideally, in my personal opinion, bit packet format should be scalable and of
variable length so that a whole v21 bit message can be treated as one single
event, if so desired by the modem and fax experts........maybe this is
future work?

Kai     

-----Original Message-----
From: Flemming Andreasen [mailto:[email-masked]]
Sent: Thursday, November 07, 2002 3:01 PM
To: Henning Schulzrinne
Cc: Miao, Kai; [email-masked]
Subject: Re: [AVT] 2833bis - V.21

Henning Schulzrinne wrote:

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

Clearly works.

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

Not a good idea IMO.

>
> - "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 reasonable option too.

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

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

>
> Flemming Andreasen wrote:
> > 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
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Carsten Waitzmann <[email-masked]>
Date: Fri, 08 Nov 2002 11:15:51 +0100

Concerning your capabilities to send V.21 bit messages the below mentioned mechanisms like V.21 compressed and, as an option
combined with 2198, looks fine to me.
However I'd like to ask whether a dedicated event for fax calls could be defined furthermore. I'm talking about a V.21 preamble flag
event, which is to be send on detection of a T.30 preamble (1s +-15% of HDLC flags). Using V.21 compressed is not very reasonable in
this case, as we don't want to send a V.21 bitstream but a single event, which corresponds to the detection of T.30 preamble.
Note: detection of T.30 preamble does not imply to wait min. 850ms, but corresponds to a minimum sequence (e.g. 7) of HDLC flags for
non-ambiguous event detection

There is a T.30 indicator value "V.21 preamble flag" already defined in T.38, however this does not help for the following reasons:
* Fax calls may be handled as "pass-through", i.e. as voice band data.
* we'd like to send this event before switching to T.38.

Could the group take this into consideration?

Thank you.

Carsten Waitzmann
Alcatel
Germany

---

From: Flemming Andreasen <[email-masked]>
Date: Sat, 09 Nov 2002 17:38:10 -0500

> Could the group take this into consideration?

Sounds reasonable to me.

-- Flemming

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 11 Nov 2002 11:45:24 -0500

> event, if so desired by the modem and fax experts........maybe this is

This is getting dangerously close to the PWE work (pseudo-wire 
emulation) or the data (clear-channel) G.711 work recently discussed 
within AVT, except that the sample rate is . I'm not sure we would need 
a separate payload type for V.21. After all, the receiver really doesn't 
much care at the bit level. The "sampling rate" would be 300 (or 37.5, 
depending on how you define a sample) and you'd just stuff bits into RTP 
frames, at whatever framing interval you find convenient. Maybe the 
clear-channel G.711 draft can be generalized accordingly.

Somebody who is following the PWE work should probably speak up and note 
whether this is just duplicating their efforts.

Also, I don't think we want to encourage raw bit transport. It's rather 
inefficient and adds complexity. After all, we hardly would want a 
recursive stack like

V.90 - PPP - IP - UDP - RTP - 2833bis/V.21 - PPP - IP - UDP - RTP - ...

Somebody has called this self-similar networking :-)