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

From: "Miao, Kai" <[email-masked]>
Date: Mon, 11 Nov 2002 15:55:12 -0500

The "v.21 message or data" inside a 2833 packet is primarily those used for
T.38, FOIP, or MOIP initiations. In T.38 that supports v.34 modem, for
example, a 30 bit (optional) CI (v.21) message is sent to the remote
(ansmer) side multiple times. Upon recerving CI, the remote side answers
with a ANSAM tone. A call that is started with a G.723.1 voice session and
is then switched over to T.38 session upon the detection of ANSAM tone by
the remote gateway......if T.38 negotiation fails, session would get
switched to a G.711 session (normally with redundancy) to perform
fax-by-pass.

Not sure how valuable it is to send a whole v21 message (this is where modem
experts could provide some clarification). But, being able to send multiple
bits (more than 6 bits) at different frame sizes is definitely a
requirement.  

BTW, T.38 protocol strips v21 flags (0x7E), so sending flags is not required
for T.38. 

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Monday, November 11, 2002 11:45 AM
To: Miao, Kai
Cc: 'Flemming Andreasen'; [email-masked]
Subject: Re: [AVT] 2833bis - V.21

Miao, Kai wrote:

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

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

> Kai

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