Subject: [avtext] Proposed resolution of the presence of VAD in client-to-mixer audio levels

From: Jonathan Lennox <[email-masked]>
Date: Fri, 29 Jul 2011 17:32:31 -0400

In the working group session on Wednesday, there was a conclusion that it would be best to signal in SDP whether an endpoint is putting meaningful VAD data into the client-to-mixer audio level extension.

My proposal is as follows.  Please give feedback on whether this satisfies everyone's objections and requirements.

There is an optional "vad" parameter defined as the extension attributes field for the "urn:ietf:params:rtp-hdrext:ssrc-audio-level" header extension element. It takes the form "vad=on" if the creator of the audio level extension is providing VAD information, and "vad=off" if it is not.

If vad=on is specified, the V bit in the audio header extension element is defined as in the current draft.  If vad=off is specified, the value of the V bit is unspecified and MUST be ignored by receivers.

If the extension attribute is not specified, the default is vad=on.

This parameter is signaled in the extension attributes; it matches RFC 5285's <extensionattributes> BNF in SDP. 

An SDP answer MUST include the same value of the vad= parameter as was contained in the offer (for the same extension-ID value), if the answer accepted the extension.

An endpoint MAY negotiate either or both variants of the extension, with the two forms having different extension ID values, using the standard RFC 5285 mechanisms.

Example SDP (showing both the syntax and the double-negotiation):

a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level vad=on
a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level vad=off

--
Jonathan Lennox
[email-masked]

---

From: Stephen Botzko <[email-masked]>
Date: Fri, 29 Jul 2011 18:47:10 -0400

It might make sense to have senders set V=0 when vad=off, rather than leave
it unspecified.

Also, if the far-end doesn't accept the extension (doesn't return vad= in
the answer), I would assume that V should be set to 0 anyway, and VAD is
off.  So I would question the default being VAD=on.  Having the default
value of on, when then far-end doesn't understand / accept the extension
seems incorrect.

Regards,
Stephen Botzko

On Fri, Jul 29, 2011 at 5:32 PM, Jonathan Lennox <[email-masked]> wrote:

> In the working group session on Wednesday, there was a conclusion that it
> would be best to signal in SDP whether an endpoint is putting meaningful VAD
> data into the client-to-mixer audio level extension.
>
> There is an optional "vad" parameter defined as the extension attributes
> field for the "urn:ietf:params:rtp-hdrext:ssrc-audio-level" header extension
> element. It takes the form "vad=on" if the creator of the audio level
> extension is providing VAD information, and "vad=off" if it is not.
>
> If vad=on is specified, the V bit in the audio header extension element is
> defined as in the current draft.  If vad=off is specified, the value of the
> V bit is unspecified and MUST be ignored by receivers.
>
> An SDP answer MUST include the same value of the vad= parameter as was
> contained in the offer (for the same extension-ID value), if the answer
> accepted the extension.
>
> An endpoint MAY negotiate either or both variants of the extension, with
> the two forms having different extension ID values, using the standard RFC
> 5285 mechanisms.
>
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext
>

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 29 Jul 2011 19:18:05 -0400

On Jul 29, 2011, at 6:47 PM, Stephen Botzko wrote:

> It might make sense to have senders set V=0 when vad=off, rather than leave it unspecified.

The motivation for leaving it unspecified was to allow a no-op conversion from vad=on to vad=off.  To be sure, (byte & 0x7f) or (byte | 0x80) isn't a very computationally-expensive operation, though. 

If we do want to set the bit to a fixed value, I think it'd be better to set V=1, since if someone's somehow confused about the setting of the vad= flag, they're better off incorrectly interpreting a packet as having voice when it doesn't, rather than incorrectly interpreting it as not having voice when it does.  

> Also, if the far-end doesn't accept the extension (doesn't return vad= in the answer), I would assume that V should be set to 0 anyway, and VAD is off.  So I would question the default being VAD=on.  Having the default value of on, when then far-end doesn't understand / accept the extension seems incorrect.

An answer with an extmap attribute whose vad= value -- specified as the extensionattributes on urn:ietf:params:rtp-hdrext:ssrc-audio-level -- doesn't match the corresponding extmap attribute in the offer would be an invalid answer, under the rules I've proposed. (It's not clear whether this is true in general for extmaps' extensionattributes values in RFC 5285, but it seems like it would be a good idea for it to be).

If you don't understand or don't want to use a extension header element, or you don't like the vad= value offered, you simply don't include the relevant extmap attribute in the SDP answer.  (This is the standard RFC 5285 offer/answer procedure.)

--
Jonathan Lennox
[email-masked]

---

From: Stephen Botzko <[email-masked]>
Date: Fri, 29 Jul 2011 19:24:23 -0400

in-line
Stephen Botzko

On Fri, Jul 29, 2011 at 7:18 PM, Jonathan Lennox <[email-masked]> wrote:

> The motivation for leaving it unspecified was to allow a no-op conversion
> from vad=on to vad=off.  To be sure, (byte & 0x7f) or (byte | 0x80) isn't a
> very computationally-expensive operation, though.
>
> If we do want to set the bit to a fixed value, I think it'd be better to
> set V=1, since if someone's somehow confused about the setting of the vad=
> flag, they're better off incorrectly interpreting a packet as having voice
> when it doesn't, rather than incorrectly interpreting it as not having voice
> when it does.
>

that is reasonable.

> An answer with an extmap attribute whose vad= value -- specified as the
> extensionattributes on urn:ietf:params:rtp-hdrext:ssrc-audio-level --
> doesn't match the corresponding extmap attribute in the offer would be an
> invalid answer, under the rules I've proposed. (It's not clear whether this
> is true in general for extmaps' extensionattributes values in RFC 5285, but
> it seems like it would be a good idea for it to be).
>
> If you don't understand or don't want to use a extension header element, or
> you don't like the vad= value offered, you simply don't include the relevant
> extmap attribute in the SDP answer.  (This is the standard RFC 5285
> offer/answer procedure.)
>
> Yes  So if vad is not included in the SDP answer, than vad is off?

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 29 Jul 2011 19:36:35 -0400

On Jul 29, 2011, at 7:24 PM, Stephen Botzko wrote:

On Fri, Jul 29, 2011 at 7:18 PM, Jonathan Lennox <[email-masked]<mailto:[email-masked]>> wrote:

If the extmap isn't included in the SDP answer, then the whole audio level extension header is off, i.e. must not be used.

If the extmap is included in the SDP answer, then whether to set the V bit in the header extension element is controlled by the value of the parameter in the answer, which must match its value in the offer.

This parameter only controls the contents of the extension header; this doesn't in any way signal or control "vad" in the sense of whether either endpoint should use silence suppression or discontinuous transmission or comfort noise or anything like that.

Would it be clearer to name the attribute something like "vbit" rather than "vad", to emphasize that this is only specifying the contents of the header extension element, not anything else?

--
Jonathan Lennox
[email-masked]<mailto:[email-masked]>