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

From: "Ido Benda" <[email-masked]>
Date: Wed, 29 Jun 2005 14:56:53 +0200

Tom,

To my understanding no gap is allowed between V.8bis message octets
(there is no NULL octet allowed within the HDLC information field of the
message). So in this case caution should be taken when implementing the
playout buffer.

Regards,
Ido Benda

> -----Original Message-----
> From: Tom Taylor [mailto:[email-masked]]
> Sent: Tuesday, June 28, 2005 18:19 PM
> To: Ido Benda
> Cc: Tom-PT Taylor; [email-masked]; Amos Agmon; Amiram Allouche
> Subject: Re: [AVT] V.8 bis events in draft-ietf-avt-2833bisdata-xx
> 
> 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?
> 
> Ido Benda wrote:
> > 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: Wed, 29 Jun 2005 08:29:09 -0400

Thanks.  I will add that advice to the V.8 bis section.

Ido Benda wrote:
> (there is no NULL octet allowed within the HDLC information field of
> the message). So in this case caution should be taken when
> implementing the playout buffer.
> 
> Regards, Ido Benda
> 
> 
> 
>> -----Original Message----- From: Tom Taylor
>> [mailto:[email-masked]] Sent: Tuesday, June 28, 2005 18:19 PM 
>> To: Ido Benda Cc: Tom-PT Taylor; [email-masked]; Amos Agmon; Amiram
>> Allouche Subject: Re: [AVT] V.8 bis events in
>> draft-ietf-avt-2833bisdata-xx
>> 
>> 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?
>> 
...