Subject: [AVT] Comments on draft-clark-avt-rtcphr-01

From: <[email-masked]>
Date: Fri, 17 Mar 2006 19:29:53 -0000

Alan, Amy, Rajesh, Kevin,

We had some final comments on draft-clark-avt-rtcphr-01 before next
week's meeting. We've sent you a marked-up document containing the
"editorial" level comments but the following might be of wider interest
so we're copying to the AVT list.

Section 2.1. We're still confused by the scenarios described by text
here and in section 3.2.1. It's very clear where both B and C are TDM-IP
gateways. However when B and C might have IP connections on both sides,
we might need to consider whether the component is an RTP end system,
mixer, translator, and which reports are relayed where and why. We think
this needs more explanation.

Section 2.2. We assume start of call will be defined at the receiver by
the first successfully-received packet, even if earlier packets are
lost. Concerning end-of-call, should it be defined that lost-packet
statistics are not reported until a later packet is successfully
received? This should not prevent generation of the dead connection
indication (Section 3.3.3) but could prevent "pollution" of the last
report of a call with spurious loss indications. For some gateways,
signalling indicating end-of-call could be used to trigger transmission
of a final report (up to and including the last successfully-received
packet) although this might not be received by a remote end which is in
the process of shutting down.

Section 3.1. Section 3 of RFC3611 specifies a block header with 1-octet
block type, 1-octet type-specific, 2-octets block length. If this is
modified, an existing RTCP-XR implementation which does not know about
RTCP-HR block type, hence wishes to ignore the RTCP-HR block, will
attempt to read a 16-bit block length. In RTCP-HR only 8 of these bits
contain block length data, so the existing implementation might get a
corrupted view of the block length. Practically this might be OK
provided the RTCP-HR block length is <256 (always true) *and* you never
use bits 8-15 of the Map field, but you've reserved all 16 bits of the
Map field for potential future use.

Section 3.6.2. To be consistent with 3.5.4, this subsection should say
that the "implementation SHOULD cause Concealed Seconds to be
incremented for 'emergency' buffer adjustments made during talkspurts"

Section 3.7.4 Y.1540 IPDV is a signed quantity with its zero position
determined by the rather arbitrary delay to the first packet, so the
average is not informative. The best quantity to use for the "Mean PDV"
might need some more thought.

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

---

From: <[email-masked]>
Date: Sun, 19 Mar 2006 23:01:00 -0800

Geoff,

Here is my response to some of the issues you raised. I refer the remaining
ones to the other co-authors.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, March 17, 2006 11:30 AM
> To: [email-masked]; [email-masked]; Kumar, Rajesh; 
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: [AVT] Comments on draft-clark-avt-rtcphr-01
> 
> We had some final comments on draft-clark-avt-rtcphr-01 
> before next week's meeting. We've sent you a marked-up 
> document containing the "editorial" level comments but the 
> following might be of wider interest so we're copying to the AVT list.
> 
> Section 2.1. We're still confused by the scenarios described 
> by text here and in section 3.2.1. It's very clear where both 
> B and C are TDM-IP gateways. However when B and C might have 
> IP connections on both sides, we might need to consider 
> whether the component is an RTP end system, mixer, 
> translator, and which reports are relayed where and why. We 
> think this needs more explanation.

Refer to other authors.

> Section 2.2. We assume start of call will be defined at the 
> receiver by the first successfully-received packet, even if 
> earlier packets are lost. Concerning end-of-call, should it 
> be defined that lost-packet statistics are not reported until 
> a later packet is successfully received? This should not 
> prevent generation of the dead connection indication (Section 
> 3.3.3) but could prevent "pollution" of the last report of a 
> call with spurious loss indications. For some gateways, 
> signalling indicating end-of-call could be used to trigger 
> transmission of a final report (up to and including the last 
> successfully-received packet) although this might not be 
> received by a remote end which is in the process of shutting down.

Refer to other authors.

> 
> Section 3.1. Section 3 of RFC3611 specifies a block header 
> with 1-octet block type, 1-octet type-specific, 2-octets 
> block length. If this is modified, an existing RTCP-XR 
> implementation which does not know about RTCP-HR block type, 
> hence wishes to ignore the RTCP-HR block, will attempt to 
> read a 16-bit block length. In RTCP-HR only 8 of these bits 
> contain block length data, so the existing implementation 
> might get a corrupted view of the block length. Practically 
> this might be OK provided the RTCP-HR block length is <256 
> (always true) *and* you never use bits 8-15 of the Map field, 
> but you've reserved all 16 bits of the Map field for 
> potential future use.

I am not aware of RTCP-XR implementations that ignore the block type. This
is not recommended behavior in RFC 3611 If there are such implementations,
then they wil run into problems, as you indicated. Should we bend the
RTCP-HR header format to accommodate such faulty design? This is a question
we must ask ourselves. If we do, then this will shrink the map field to one
octer, which is certainly sufficient for current needs, albeit limited in
terms of future extensibility.

> 
> Section 3.6.2. To be consistent with 3.5.4, this subsection 
> should say that the "implementation SHOULD cause Concealed 
> Seconds to be incremented for 'emergency' buffer adjustments 
> made during talkspurts"

I agree. How about the following text, which IMO is even better:

   An implementation SHOULD cause Concealed Seconds to be incremented for
any 
   audible buffer adjustments such as 'emergency' adaptations and
   unsophisticated adaptations during speech without 
   regard for the underlying signal.

I haven't checked this with Alan, Amy and Kevin, so, for now, it is just my
suggestion and not a commitment to insert the suggested text.

> 
> Section 3.7.4 Y.1540 IPDV is a signed quantity with its zero 
> position determined by the rather arbitrary delay to the 
> first packet, so the average is not informative. The best 
> quantity to use for the "Mean PDV" might need some more thought.

Refer to other authors.

Thanks.

Rajesh