Subject: RE: [AVT] V.8 bis events in draft-ietf-avt-2833bisdata-xx

From: "Ido Benda" <[email-masked]>
Date: Tue, 28 Jun 2005 18:36:28 +0200

Hi Tom,

V.8bis is becoming common as part of the V.92 quick connect capability,
and as such should be supported in the RFC2833bis.

I agree with you that you should define these two events to avoid a
propagating delay, but I suggest you will change the current V.8bis
events to be defined as the single tone only (i.e. segment 2), as it is
specified in the V.8bis standard. In this way you could implement for
example the sending of CRdi as two events: 
* 'V.8 initiating' with timestamp X and duration increasing to 400ms
(Y),
* 'CRd' with timestamp X+Y and duration increasing to 100ms.

This is probably more aligned with a simple detector implementation in
voice channels, and more intuitive in the event generator on the far
end.

Regarding the congestion handling analysis, I am not sure what exactly
the issue is. If you can specify, we may be of some assistance...

Regards,
Ido Benda

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tom Taylor
Sent: Tuesday, June 28, 2005 1:06 AM
To: [email-masked]
Subject: [AVT] V.8 bis events in draft-ietf-avt-2833bisdata-xx

I've modified draft-ietf-avt-2833bisdata-xx as previously agreed on the 
list, but have hesitated over what to say about congestion handling.  A 
proper analysis requires that I go over each of the various modem 
protocols and figure out how vulnerable it is to playout gaps.  It would

be much easier if I had expert advice to help me.  I may seek such 
advice from Study Group 16 next week.

I have another issue: the current V.8 bis events don't make sense to me.

  The problem is that V.8 bis signals start with a 400 ms initial 
segment that doesn't select which event will be reported, only whether 
this is an initiating or a responding signal.  So it is only 400+ ms 
into the signal that the sender can decide what event to report.  That's

quite a buffer lag.

The lag may make sense if the gateway is using V.150.1 modem relay, 
since in that case the sender is supposed to block V.8 bis signals from 
appearing in-band on the IP side of the gateway.  I'm not sure if it 
makes sense in other applications.

What would make sense is to add two more events to indicate detection of

a V.8 bis initiating signal or responding signal respectively.

I suspect V.8 bis is a bit of an orphan and not widely implemented.  Am 
I fussing too much or do the additional events make sense?

Tom Taylor

_______________________________________________
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: Tom Taylor <[email-masked]>
Date: Tue, 28 Jun 2005 12:19:26 -0400

Thank you very much for your response.

Your proposal for the V.8 bis events is exactly what I had in mind.

On congestion: the issue is what happens when packets arrive late at the 
receiving end.  To take the specific example of V.8 bis, suppose that in 
the middle of one of the messages, a packet arrives late, so there is a 
gap in time between playout of one octet and the next.  Can such a gap 
be tolerated at the receiving modem?