Subject: [AVT] RE: RTCP XR comments

From: "Alan Clark" <[email-masked]>
Date: Wed, 7 May 2003 23:35:16 -0400

Colin

Section 4.7.3

With regard to your comment concerning end systems that are receive-only or
streaming, I'd like to keep the delay related metrics mandatory for
conversational applications as delay is a significant impairment factor.
I suggest that we change "This value MUST be provided in all VoIP metrics
reports" to "This value MUST be provided in all VoIP metrics reports that
relate to two-party real-time interactive or conversational RTP sessions and
MAY be provided for multi-party conference or streaming applications."

Section 4.7.4 Residual Echo Return Loss

On draft 05 page 32 I suggest adding the following after the paragraph "The
ERL and ERLE parameters are
often..........................................network attached to the
endpoint.

The Residual Echo Return Loss value may be measured directly by the VoIP end
system's Echo Canceller or may be estimated by adding the Echo Return Loss
and Echo Return Loss Enhancement (ERLE) values reported by the Echo
Canceller.

	RERL(dB) = ERL (dB) + ERLE (dB)

In the case of a VoIP gateway the source of echo is typically line echo that
occurs at 2-4 wire conversion points in the network.  Echo Return Loss from
typical 2-4 wire conversion points........(existing paragraph)

Section 4.7.5

Suggest changing PLC description to

"When PLC = 11 then a simple replay or interpolation algorithm is being used
to fill-in the missing packet; this approach is typically able to conceal
isolated lost packets at low packet loss rates.  When PLC = 10 then an
enhanced interpolation algorithm is being used; algorithms of this type are
able to conceal high packet loss rates effectively.  When PLC = 01 then
silence is being inserted in place of lost packets.  When PLC = 00 then no
information is available concerning the use of PLC however for some codecs
this may be inferred."

Appendix A.2
The software example in Appendix A.2 has been verified against a working
implementation for correctness.  The ETSI document provided an algorithm
description.  Appendix A.2 should take precedence.

Regards

Alan Clark
Telchemy

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

---

From: Colin Perkins <[email-masked]>
Date: Fri, 09 May 2003 11:30:43 -0400

Alan,

>MAY be provided for multi-party conference or streaming applications."

How about: "This value SHOULD be provided in all VoIP metrics reports.  If
an implementation is unable to provide the data, the value 0 MUST be used."

>typical 2-4 wire conversion points........(existing paragraph)

This is a good addition, but my concern was about the typical values
discussion which seems to imply particular implementation strategies. 
I suggest deleting everything from the paragraph that begins "In the 
case of a VoIP gateway..." to the Gmin discussion? Or, at least, re-
writing it in a manner independent of particular implementations.

>information is available concerning the use of PLC however for some codecs

Much better, thanks.

>description.  Appendix A.2 should take precedence.

Okay.

Thanks,
Colin

---

From: "Alan Clark" <[email-masked]>
Date: Fri, 9 May 2003 17:42:46 -0400

Colin

[Alan] That is acceptable

[Alan] Actually the description is more geared around the defaults and
recommendations of typical TIA and ITU standards and is not oriented towards
any specific implementations.  If this is not apparent or if the text does
not add anything then we could delete it as suggested.

Regards

Alan

---

From: Colin Perkins <[email-masked]>
Date: Mon, 12 May 2003 11:51:21 +0100

--> "Alan Clark" writes:
...
>not add anything then we could delete it as suggested.

Right, but the draft uses normative language in this section, based around
particular implementation choices. If you can rewrite the text from "For an
IP phone with handset this metric MUST..." until the discussion of Gmin, so
that it describes examples of how particular systems calculate the metric,
without using normative (RFC 2119) language, that would be acceptable.

Colin

---

From: "Alan Clark" <[email-masked]>
Date: Mon, 12 May 2003 10:04:53 -0400

Colin

Would this revised text be acceptable?

Regards

Alan

   The Residual Echo Return Loss value may be measured directly by the
   VoIP end system's Echo Canceller or may be estimated by adding the
   Echo Return Loss and Echo Return Loss Enhancement (ERLE) values
   reported by the Echo Canceller.

   In the case of a VoIP gateway the source of echo is typically line
   echo that occurs at 2-4 wire conversion points in the network. This
   can be in the 8-12 dB range. A line echo canceler can provide an ERLE
   of 30 dB or more and hence reduce this to 40-50 dB.  In the case of
   an IP phone this could be acoustic coupling between handset speaker
   and microphone or residual acoustic echo from speakerphone operation,
   and may more correctly be termed terminal coupling loss (TCL). A
   typical handset would result in 40-50 dB of echo "loss" due to
   acoustic feedback.

   Examples:

   (i) IP gateway connected to circuit switched network with 2 wire loop
   Without echo cancellation, typical 2-4 wire converter ERL of 12 dB
   RERL = ERL + ERLE = 12 + 0 = 12 dB

   (ii) IP gateway connected to circuit switched network with 2 wire loop
   With echo canceler that improves echo by 30 dB
   RERL = ERL + ERLE = 12 + 30 = 42 dB

   (iii) IP phone with conventional handset
   Acoustic coupling from handset speaker to microphone ("Terminal
   Coupling Loss") is typically 40 dB.
   RERL = TCL = 40 dB

   If we denote the "local" end of the VoIP path as A and the remote end
   as B and if the sender loudness rating (SLR) and receiver loudness
   rating (RLR) are known for A (default values 8 dB and 2 dB
   respectively), then the echo loudness level at end A (talker echo
   loudness rating or TELR) is given by:

   TELR(A) = SRL(A) + ERL(B) + ERLE(B) + RLR(A)

   TELR(B) = SRL(B) + ERL(A) + ERLE(A) + RLR(B)

   Hence in order to incorporate echo into a voice quality estimate at
   the A end of a VoIP connection it is desirable to send the ERL + ERLE
   value from B to A using a protocol such as RTCP XR.

   Echo related information may not be available in all VoIP end
   systems. As Echo does have a significant effect on conversational
   quality it is recommended that estimated values for Echo Return Loss
   and Terminal Coupling Loss be provided (if sensible estimates can be
   reasonably determined).

   Typical values for end systems are given below to provide guidance:

   (a) IP Phone with handset - typically 45 dB

   (b) PC softphone or speakerphone - extremely variable, consider
   reporting "undefined" (127).

   (c) IP gateway with line echo canceller - typically has ERL and ERLE
   available

   (d) IP gateway without line echo canceller - frequently a source of
   echo related problems, consider reporting either a low value (12db)
   or "undefined" (127).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Colin
Perkins
Sent: Monday, May 12, 2003 6:51 AM
To: [email-masked]; Timur Friedman
Subject: Re: [AVT] RE: RTCP XR comments

--> "Alan Clark" writes:
...

Colin

---

From: Colin Perkins <[email-masked]>
Date: Tue, 13 May 2003 22:30:10 +0100

>Would this revised text be acceptable?

Yes, thanks!

Colin