Subject: [avtext] WGLC for draft-ietf-avtext-client-to-mixer-audio-level-03

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 6 Jul 2011 16:22:11 +0200

(As WG cochair)

This is to announce a Working Group Last Call on 

draft-ietf-avtext-client-to-mixer-audio-level-03

(Do note this is two parallel calls on two related drafts)

Please review and supply comments by Wednesday 20th July 2011.

It is helpful if you make some attempt to categorise uour comments, e.g. Major, Minor technical, Editorial.

If you review the document and find no issue with the current version, then it is helpful to send a mail to the WG chairs saying so as this helps us assess the level of review.

Regards

Keith

P.S. The intent is to allow any identified show stoppers to be discussed at the face to face in Quebec, so the earlier such comments are made the better.

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 12 Jul 2011 17:04:44 -0500

> If you review the document and find no issue with the current version, then it is helpful to send a mail to the WG chairs saying so as this helps us assess the level of review.

Editorial:

Paragraph 2 of Section 3 - "using the one or the two-byte header" seems 
to be a bit hard to parse. Maybe "using either the one-byte or the 
two-byte header format" would be better?

Last paragraph of Section 3 - 'noice' should be 'noise'

Minor technical:

Should there be any text included to indicate that a mixer receiving RTP 
packets with these header extensions should recognize that an SSRC 
change means that the client's behavior regarding this extension may 
also change? For example, when the session is first established, the 
client may be using the 'V' flag to reliably indicate the presence of 
voice in the audio payload... but after an SSRC change to a new client 
source, the 'V' flag may no longer be used at all. The 'design guidance' 
section does warn implementors that they may need to double-check the 
audio level (and 'V' flags) reported by the client, but a specific 
warning that this will almost always be necessary after an SSRC change 
might be useful as well.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email-masked] | SIP: [email-masked] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 13 Jul 2011 17:22:13 +0200

Hi,

I have reviewed this new version and have the following comments:

>From my previous review that I don't believe got answered.

1. Section 3:
   In addition, a flag bit (labeled V) indicates whether the encoder
   believes the audio packet contains voice activity (1) or does not
   (0).  The voice activity detection algorithm is unspecified and left
   implementation-specific.

Would it be of interest to have an signalling parameter for an
implementation to indicate its algorithm?

The reason I am coming back to this, is that if you don't know if it is
used, how can you then use the V bit. Is V=0 because there is no voice
activity or because there is no VAD implemented.

One can also expand the question to what a media sender without VAD
should set as value for V.

2. Section 6.
"One solution is header
   extension encryption [I-D.lennox-avtcore-srtp-encrypted-header-ext]."

I think the formulation of also pointing to lower layer solution is
appropriate. If one uses DTLS (without SRTP based media protection),
TLS, IPsec etc then this information would not be visible.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 14 Jul 2011 18:49:47 -0400

> implementation to indicate its algorithm?

I'm not sure whether the algorithm, specifically, is useful (it'd require establishing an IANA registry of specific VAD algorithms), but I could imagine that some way of indicating VAD used/not-used could be useful.

An alternative would be to mandate that use of the extension implies that you're sending meaningful VAD.

> TLS, IPsec etc then this information would not be visible.

Okay.  The intention is to follow the same general pattern as srtp-not-mandatory, so we'll see if we can re-use some language from there, and also reference it.

--
Jonathan Lennox
[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 15 Jul 2011 16:01:47 +0200

On 2011-07-15 00:49, Jonathan Lennox wrote:
>> 1. Section 3: In addition, a flag bit (labeled V) indicates whether
>> the encoder believes the audio packet contains voice activity (1)
>> or does not (0).  The voice activity detection algorithm is
>> unspecified and left implementation-specific.
>> 
> I'm not sure whether the algorithm, specifically, is useful (it'd
> require establishing an IANA registry of specific VAD algorithms),
> but I could imagine that some way of indicating VAD used/not-used
> could be useful.
> 

Yes, I think signalling if a client use VAD or not would be most
appropriate solution.

> 
>> 2. Section 6. "One solution is header extension encryption
>> [I-D.lennox-avtcore-srtp-encrypted-header-ext]."
>> 
>> I think the formulation of also pointing to lower layer solution
>> is appropriate. If one uses DTLS (without SRTP based media
>> protection), TLS, IPsec etc then this information would not be
>> visible.
> 
> Okay.  The intention is to follow the same general pattern as
> srtp-not-mandatory, so we'll see if we can re-use some language from
> there, and also reference it.

In this case you could just copy the corresponding sentence from the
mixer to client draft.

Cheers

Magnus Westerlund