Subject: [Perc] DTMF and Double

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 4 Apr 2017 12:22:31 +0200

Hi all,

Hate to ask this, but I have one more doubt when making changes to 
libwertc to support double. Should DTMF be also double protected or we 
should send it HBH?

At least on webrtc, browsers are only meant to send DTMF, not receive 
them, so it would make sense to end them at the SFU and not propagate it 
to the other participants.

Best regards

Sergio

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 4 Apr 2017 06:23:43 -0700

On Tue, Apr 4, 2017 at 3:22 AM, Sergio Garcia Murillo <
[email-masked]> wrote:

> them, so it would make sense to end them at the SFU and not propagate it to
> the other participants.
>

I'm not following this reasoning. DTMF is media, so it should behave like
other
media.

-Ekr

Best regards
>
> Sergio
>
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 4 Apr 2017 15:37:16 +0200

On 04/04/2017 15:23, Eric Rescorla wrote:
>
>
> On Tue, Apr 4, 2017 at 3:22 AM, Sergio Garcia Murillo 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>     libwertc to support double. Should DTMF be also double protected
>     or we should send it HBH?
>
>     At least on webrtc, browsers are only meant to send DTMF, not
>     receive them, so it would make sense to end them at the SFU and
>     not propagate it to the other participants.
>
>
> I'm not following this reasoning. DTMF is media, so it should behave 
> like other
> media.

DTMF is media, for some definitions of media.. :)

Avoiding the issue that using DTMF on webrtc is kind of, well, you know, 
my point is that there is no sense in forwarding DTMF to the meeting 
participants, as it is typically consumed by the media servers and also 
webrtc browsers don't allow to receive it in JS.

Being imaginative, I can think in a use case when DTMF in PERC could 
make sense, for example to join PSTN participants into a conference. In 
this scenario, you will allow the participant to perform some operations 
via DTMF, and this operations would be done in the SFU, so the SFU needs 
to end the DTMF, and DTMF can't be E2E.

Best regards
Sergio

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 4 Apr 2017 08:25:53 -0700

On Tue, Apr 4, 2017 at 6:37 AM, Sergio Garcia Murillo <
[email-masked]> wrote:

> Being imaginative, I can think in a use case when DTMF in PERC could make
> sense, for example to join PSTN participants into a conference. In this
> scenario, you will allow the participant to perform some operations via
> DTMF, and this operations would be done in the SFU, so the SFU needs to end
> the DTMF, and DTMF can't be E2E.
>

Then you should create a separate channel, not make an exception.

-Ekr

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 4 Apr 2017 17:48:45 +0200

On 04/04/2017 17:25, Eric Rescorla wrote:
>
>
> On Tue, Apr 4, 2017 at 6:37 AM, Sergio Garcia Murillo 
>>         Hate to ask this, but I have one more doubt when making
>>         changes to libwertc to support double. Should DTMF be also
>>         double protected or we should send it HBH?
>>
>>         receive them, so it would make sense to end them at the SFU
>>         and not propagate it to the other participants.
>>
>>
>>     I'm not following this reasoning. DTMF is media, so it should
>>     behave like other
>>     media.
>
>     Avoiding the issue that using DTMF on webrtc is kind of, well, you
>     know, my point is that there is no sense in forwarding DTMF to the
>     meeting participants, as it is typically consumed by the media
>     servers and also webrtc browsers don't allow to receive it in JS.
>
>     Being imaginative, I can think in a use case when DTMF in PERC
>     could make sense, for example to join PSTN participants into a
>     conference. In this scenario, you will allow the participant to
>     perform some operations via DTMF, and this operations would be
>     done in the SFU, so the SFU needs to end the DTMF, and DTMF can't
>     be E2E.
>
>

DTMF is already an exception, anyway, I am fine making DTMF in webrtc 
non functional with PERC.

Best regards
Sergio

---

From: Nils Ohlmeier <[email-masked]>
Date: Tue, 4 Apr 2017 11:32:23 -0700

> On Apr 4, 2017, at 08:48, Sergio Garcia Murillo <[email-masked]> wrote:
> 
> 
> DTMF is already an exception, anyway, I am fine making DTMF in webrtc non functional with PERC.

+1 for declaring that DTMF is not going to be supported by PERC.
Especially since the only use case I see would be trying to connect a PERC call with double encryption to something in a legacy network without any encryption at all, which appears like a bad idea to start with.

  Nils

---

From: Simon Perreault <[email-masked]>
Date: Tue, 4 Apr 2017 14:37:47 -0400

> +1 for declaring that DTMF is not going to be supported by PERC.

DTMF will work fine. It's just the relay that won't have access to it.
Endpoints will get DTMF as usual.

> Especially since the only use case I see would be trying to connect a PERC call with double encryption to something in a legacy network without any encryption at all, which appears like a bad idea…

Real-world use cases for DTMF in conferences:

- 3-way call where one user is helping another navigate an IVR.

- Dialing out from a conference to a PSTN user and having to enter the
user's extension number as DTMF.

Those should still work with PERC, as far as I know. Using a PERC/PSTN
gateway, of course.

-- 
Simon Perreault
Director of Engineering, Platform | Jive Communications, Inc.
https://jive.com | +1 418 478 0989 ext. 1241 | [email-masked]

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 4 Apr 2017 20:43:32 +0200

> Endpoints will get DTMF as usual.

WebRTC only supports sending DTMF not receiving it.

> user's extension number as DTMF.
That won't work as that would be have to be performed on the 
conferencing server, which will not have access to the DTMF data if it 
is E2E.

BR
Sergio

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 4 Apr 2017 14:45:57 -0400

> Especially since the only use case I see would be trying to connect a PERC call with double encryption to something in a legacy network without any encryption at all, which appears like a bad idea…

Are you talking about DTMF via RTP (Telephone Events) or DTMF in the 
signaling channel?

DTMF via RTP is just another codec. IIUC PERC is agnostic to codec, so 
why would you be singling it out?

Whether DTMF is supported with PERC in webrtc is a separate question. It 
gets tied up in UI, and I can see how it might not be supported. But 
that is more about webrtc than it is about PERC.

	Thanks,
	Paul

---

From: Simon Perreault <[email-masked]>
Date: Tue, 4 Apr 2017 14:47:31 -0400

> WebRTC only supports sending DTMF not receiving it.

Uh?

> conferencing server, which will not have access to the DTMF data if it

Uh?

You appear to be misinformed.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 4 Apr 2017 20:51:34 +0200

>> WebRTC only supports sending DTMF not receiving it.
https://tools.ietf.org/html/rfc7874
WebRTC only mandates sending DTMF, please check where it says anything 
about receiving it.

Also, please, point me out which w3c apis are available to receive those 
events:
https://www.w3.org/TR/webrtc/#peer-to-peer-dtmf

> You appear to be misinformed.
Could you be more precise in which part I am misinformed?

Best regards
Sergio

---

From: Adam Roach <[email-masked]>
Date: Tue, 4 Apr 2017 13:55:50 -0500

[as individual]

> why would you be singling it out? 

Yes. This is the right answer.

/a

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 4 Apr 2017 20:53:45 +0200

On 04/04/2017 20:45, Paul Kyzivat wrote:
>> Especially since the only use case I see would be trying to connect a 
>> PERC call with double encryption to something in a legacy network 
>> without any encryption at all, which appears like a bad idea to start 
>> with.
>
telephone-events
> why would you be singling it out?

PERC, at least double should not be codec agnostic, at least to be able 
to do RTX/FEC/RED/Flex-FEC HBH.

The question is if DTMF should be HBH or E2E, and in a conferencing 
environment I see no use of E2E DTMF at all. Please correct me if you 
see it otherwise.

Regards
Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 4 Apr 2017 21:11:45 +0200

El 4/4/2017 20:56, "Adam Roach" <[email-masked]> escribió:

[as individual]

On 4/4/17 13:45, Paul Kyzivat wrote:

> DTMF via RTP is just another codec. IIUC PERC is agnostic to codec, so why
> would you be singling it out?
>

Yes. This is the right answer

Have to disagree. I think one of the key questions in PERC is to define
what makes sense in conferencing environment to be HBH and what E2E.

And an SFU developer, IMO the following ones only make sense to be HBH:

-RTP header extensions
-RTX
-RED
-FEC
-Flex FEC
-DTMF

Pretending to make PERC agnostic and just tunnel everything E2E is not
going to work.

Best regards
Sergio

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 4 Apr 2017 15:30:33 -0400

> to do RTX/FEC/RED/Flex-FEC HBH.

These are "special" - not really codecs, and so may well require some 
special handling.

> environment I see no use of E2E DTMF at all. Please correct me if you

IMO DTMF is a "normal" codec, like G711, and ought to be treated the same.

Hence the conferencing equipment won't have access to it unless also 
acting as an endpoint. That does seem to exclude using it for 
controlling the properties of the conference.

Whether the participants in the conference can use received DTMF in any 
meaningful way is a separate question. Often they won't, and that may be 
the case for webrtc participants. But as somebody mentioned, one of the 
participants might be an IVR that *could* make use of it.

	Thanks,
	Paul

---

From: Nils Ohlmeier <[email-masked]>
Date: Tue, 4 Apr 2017 12:43:59 -0700

> On Apr 4, 2017, at 12:30, Paul Kyzivat <[email-masked]> wrote:
> 

I’m not sure I would call DTMF “normal”, but that is splitting hairs.

> Hence the conferencing equipment won't have access to it unless also acting as an endpoint. That does seem to exclude using it for controlling the properties of the conference.
> 
> Whether the participants in the conference can use received DTMF in any meaningful way is a separate question. Often they won't, and that may be the case for webrtc participants. But as somebody mentioned, one of the participants might be an IVR that *could* make use of it.

I agree.

What I meant to say earlier, apology for not being more precise, was that I would be opposed to put in extra effort to make DTMF work in a HBH way towards the MD. If endpoints want to utilize DTMF E2E that is up to them.
I guess what is going to be challenging is to get something like DTMF negotiated E2E. But that is somewhat different topic.

Best
  Nils

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 4 Apr 2017 22:02:48 +0200

On 04/04/2017 21:43, Nils Ohlmeier wrote:
>
>> On Apr 4, 2017, at 12:30, Paul Kyzivat <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>
>> Whether the participants in the conference can use received DTMF in 
>> any meaningful way is a separate question. Often they won't, and that 
>> may be the case for webrtc participants. But as somebody mentioned, 
>> one of the participants might be an IVR that *could* make use of it.
>
> I agree.
>
> What I meant to say earlier, apology for not being more precise, was 
> that I would be opposed to put in extra effort to make DTMF work in a 
> HBH way towards the MD. If endpoints want to utilize DTMF E2E that is 
> up to them.
> I guess what is going to be challenging is to get something like DTMF 
> negotiated E2E. But that is somewhat different topic.

I agree also, I raised the question because when implementing double in 
libwertc it was more complex to get DTMF as E2E than keeping it HBH as 
the code to handle the audio media and telephone-events are in different 
places.

Regards
Sergio

---

From: Stephen Botzko <[email-masked]>
Date: Wed, 5 Apr 2017 10:25:58 -0400

> Yes. This is the right answer.
[SB] The point here was that DTMF over RTP secured with double can *only*
be used end-to-end *unless* you treat it as a special case.  Choosing to
treat it as "any other codec" means the MD cannot use DTMF to extend
conference functions that it might have.  Most traditional MCUs do use DTMF
to extend conference controls.  Personally I don't see that as a problem
for PERC, and potentially allowing an actor w/o the e2e key access to
control conference functions is a bad idea.

There are two other unusual cases I know of - Far End Camera Control over
RTP (RFC 4573) and Text over RTP (RFC 4103)

At first glance RFC 4573 appears to work with double and PERC generally for
it's intended use of camera control.  There is at least one MCU that uses
RFC 4573 for conference control, and that particular use won't work for
MDs.  That's not a problem for me.

I believe RFC 4103 also works.  There is information leakage in the packet
lengths unless some form of padding is provided, and the use of marker bits
also leaks some information.  RFC 4103 is old, and it's security
considerations doesn't mention either of these.  RFC 6562 could apply, but
it's scope is limited specifically to VBR audio, and RFC 4103 is not that.
Stopping those leaks is not a PERC issue of course, but might be something
that AVT should clean up.

Paul K and Paul J -  In a conference where accessibility is needed, does
there need to be some way for the MD to manage distribution of text?  I
don't believe PERC provides that, and it might be hard to do. [/SB]

---

From: Stephen Botzko <[email-masked]>
Date: Wed, 5 Apr 2017 10:35:20 -0400

>>>*potentially allowing an actor w/o the e2e key access to control
conference functions is a bad idea.*
We might have this issue already, since SRTCP is h2h.  That needs to be
added to the security considerations.

Stephen

On Wed, Apr 5, 2017 at 10:25 AM, Stephen Botzko <[email-masked]>
wrote:

> At first glance RFC 4573 appears to work with double and PERC generally
> for it's intended use of camera control.  There is at least one MCU that
> uses RFC 4573 for conference control, and that particular use won't work
> for MDs.  That's not a problem for me.
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 05 Apr 2017 15:26:49 +0000

Steve,

I would expect the MD to just send any incoming RFC 4103 packets to all 
other participants in the conference.  How that text is rendered would 
be a local issue.  The MD really cannot do anything else with those 
packets, nor should it, really.  Often, RFC 4103 is used with RFC 2198.  
However, I see no reason for that to not go E2E, as well.

In terms of security, figuring out the security weaknesses is tough.  
The RFC 4103 payload is whatever characters the user types within a 
buffering period.  There are no word boundaries, just characters 
collected over a period of time.  There might be as little as one 
character per packet if the typist is slow.  I think it would be hard to 
figure out what is being typed.  However, one could perhaps get a hint 
about typing rate (modulo the fact that text is buffered for a period of 
time), that text might have been copied and pasted into a chat window, 
or guess at some test.  As an example of the latter, characters can be 
counted, so seeing one to 5 packets with a total of five characters 
followed by a long pause (>=1 buffering period) might suggest the word 
"hello" was typed.  In any case, an attack would require looking at 
string lengths and pauses where a buffering period passes where no text 
is sent.  It would interesting if people are aware of exploits of a 
similar nature.  Perhaps as a means of mitigating even those potential 
exploits, we might recommend to pad the transmitted packets.  I'm not 
sure what might be most appropriate, but Unicode does define a 
zero-width space (U+200B).

I copied Gunnar, as he always has insight to add on these matters.

Paul

------ Original Message ------
From: "Stephen Botzko" <[email-masked]>
To: "Adam Roach" <[email-masked]>
Cc: "Paul Kyzivat" <[email-masked]>; [email-masked]
Sent: 4/5/2017 10:25:58 AM
Subject: Re: [Perc] DTMF and Double

>>>DTMF via RTP is just another codec. IIUC PERC is agnostic to codec, 
>>>so why would you be singling it out?
>>
>>
>[SB] The point here was that DTMF over RTP secured with double can only 
>be used end-to-end unless you treat it as a special case.  Choosing to 
>conference functions that it might have.  Most traditional MCUs do use 
>DTMF to extend conference controls.  Personally I don't see that as a 
>problem for PERC, and potentially allowing an actor w/o the e2e key 
>access to control conference functions is a bad idea.
>
>
>There are two other unusual cases I know of - Far End Camera Control 
>over RTP (RFC 4573) and Text over RTP (RFC 4103)
>
>for it's intended use of camera control.  There is at least one MCU 
>that uses RFC 4573 for conference control, and that particular use 
>won't work for MDs.  That's not a problem for me.
>
>I believe RFC 4103 also works.  There is information leakage in the 
>packet lengths unless some form of padding is provided, and the use of 
>marker bits also leaks some information.  RFC 4103 is old, and it's 
>security considerations doesn't mention either of these.  RFC 6562 
>could apply, but it's scope is limited specifically to VBR audio, and 
>RFC 4103 is not that.  Stopping those leaks is not a PERC issue of 
>course, but might be something that AVT should clean up.
>
>
>Paul K and Paul J -  In a conference where accessibility is needed, 
>does there need to be some way for the MD to manage distribution of 
>text?  I don't believe PERC provides that, and it might be hard to do. 
>[/SB]
>
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 05 Apr 2017 15:32:21 +0000

I would not worry about that, either.  The primary objective of PERC is 
to ensure E2E privacy of the conversation.  The MD, if compromised, can 
send media to the wrong place, discard it, etc.  PERC never had an 
objective to prevent DOS attacks of any form.

Paul

------ Original Message ------
From: "Stephen Botzko" <[email-masked]>
To: "Adam Roach" <[email-masked]>
Cc: "Paul Kyzivat" <[email-masked]>; [email-masked]
Sent: 4/5/2017 10:35:20 AM
Subject: Re: [Perc] DTMF and Double

> >>>potentially allowing an actor w/o the e2e key access to control 
>conference functions is a bad idea.
>On Wed, Apr 5, 2017 at 10:25 AM, Stephen Botzko 
><[email-masked]> wrote:
>>
>>
>>[SB] The point here was that DTMF over RTP secured with double can 
>>only be used end-to-end unless you treat it as a special case.  
>>Choosing to treat it as "any other codec" means the MD cannot use DTMF 
>>to extend conference functions that it might have.  Most traditional 
>>MCUs do use DTMF to extend conference controls.  Personally I don't 
>>see that as a problem for PERC, and potentially allowing an actor w/o 
>>the e2e key access to control conference functions is a bad idea.
>>
>>
>>At first glance RFC 4573 appears to work with double and PERC 
>>generally for it's intended use of camera control.  There is at least 
>>one MCU that uses RFC 4573 for conference control, and that particular 
>>use won't work for MDs.  That's not a problem for me.
>>

---

From: Stephen Botzko <[email-masked]>
Date: Wed, 5 Apr 2017 13:49:35 -0400

Of course the MD can execute a wide range of DOS attacks.

SRTCP today is always h2h, so PERC doesn't open any new doors here.  But
the implications of e2e SRTP and h2h SRTCP with a semi-trusted MD isn't
described in double security considerations at all.

There is a lot of stuff that is sent over RTCP.  Some of these things can
also be sent over RTP (for instance per RFC 7941), and if the MD doesn't
need those things, perhaps they should be sent only over RTP with PERC.
And of course things the MD does need must be sent over RTCP.

Anyway, my original "might have this issue" was simply a realization that I
hadn't actually considered the full range of information (status, feedback,
etc) that can sent over RTCP.  In addition to the attacks you list in your
framework draft, a compromised MD can also use TMMBR and other RTCP
controls to attack a conference.

Stephen

On Wed, Apr 5, 2017 at 11:32 AM, Paul E. Jones <[email-masked]>
wrote:

> I would not worry about that, either.  The primary objective of PERC is to
> ensure E2E privacy of the conversation.  The MD, if compromised, can send
> media to the wrong place, discard it, etc.  PERC never had an objective to
> prevent DOS attacks of any form.
>
> Paul
>
>> security considerations doesn't mention either of these.  RFC 6562 could
>> apply, but it's scope is limited specifically to VBR audio, and RFC 4103 is
>> not that.  Stopping those leaks is not a PERC issue of course, but might be
>> something that AVT should clean up.
>>
>>

---

From: Stephen Botzko <[email-masked]>
Date: Wed, 5 Apr 2017 14:00:31 -0400

>>>I would expect the MD to just send any incoming RFC 4103 packets to all
other participants in the conference
I was hoping that was sufficient.

>>> I'm not sure what might be most appropriate, but Unicode does define a
zero-width space (U+200B).
RTP padding is likely enough, and if the max characters per packet is small
the character count might already be reasonably masked by the AES block
size.

The idle is harder to solve (which relates to the marker bit use).  That
does provide leakage about when people are talking, and perhaps the length
of each remark.

Steve

On Wed, Apr 5, 2017 at 11:26 AM, Paul E. Jones <[email-masked]>
wrote:

> other participants in the conference.  How that text is rendered would be a
> local issue.  The MD really cannot do anything else with those packets, nor
> should it, really.  Often, RFC 4103 is used with RFC 2198.  However, I see
> no reason for that to not go E2E, as well.
>
> In terms of security, figuring out the security weaknesses is tough.  The
> RFC 4103 payload is whatever characters the user types within a buffering
> period.  There are no word boundaries, just characters collected over a
> period of time.  There might be as little as one character per packet if
> the typist is slow.  I think it would be hard to figure out what is being
> typed.  However, one could perhaps get a hint about typing rate (modulo the
> fact that text is buffered for a period of time), that text might have been
> copied and pasted into a chat window, or guess at some test.  As an example
> of the latter, characters can be counted, so seeing one to 5 packets with a
> total of five characters followed by a long pause (>=1 buffering period)
> might suggest the word "hello" was typed.  In any case, an attack would
> require looking at string lengths and pauses where a buffering period
> passes where no text is sent.  It would interesting if people are aware of
> exploits of a similar nature.  Perhaps as a means of mitigating even those
> potential exploits, we might recommend to pad the transmitted packets.  I'm
> not sure what might be most appropriate, but Unicode does define a

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 06 Apr 2017 02:44:17 +0000

Steve,

Yeah, you're correct.  I recall in one meeting we discussed explaining 
that one ought not send sensitive information over RTCP, but that never 
founds its way into the text.  It might be in the architecture document 
and, IMO, that's the right place to put it, since it frames the whole 
model.

Not sure how to deal with encrypted header extensions in light of recent 
discussion here on the list.  Topic for an interim meeting, perhaps.

Paul

------ Original Message ------
From: "Stephen Botzko" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>
Cc: "Adam Roach" <[email-masked]>; "Paul Kyzivat" 
<[email-masked]>; [email-masked]
Sent: 4/5/2017 1:49:35 PM
Subject: Re: [Perc] DTMF and Double

>SRTCP today is always h2h, so PERC doesn't open any new doors here.  
>But the implications of e2e SRTP and h2h SRTCP with a semi-trusted MD 
>isn't described in double security considerations at all.
>
>There is a lot of stuff that is sent over RTCP.  Some of these things 
>can also be sent over RTP (for instance per RFC 7941), and if the MD 
>doesn't need those things, perhaps they should be sent only over RTP 
>with PERC.  And of course things the MD does need must be sent over 
>RTCP.
>
>Anyway, my original "might have this issue" was simply a realization 
>that I hadn't actually considered the full range of information 
>(status, feedback, etc) that can sent over RTCP.  In addition to the 
>attacks you list in your framework draft, a compromised MD can also use 
>TMMBR and other RTCP controls to attack a conference.
>
>Stephen
>
>>I would not worry about that, either.  The primary objective of PERC 
>>is to ensure E2E privacy of the conversation.  The MD, if compromised, 
>>can send media to the wrong place, discard it, etc.  PERC never had an 
>>>We might have this issue already, since SRTCP is h2h.  That needs to 
>>>be added to the security considerations.
>>>
>>>Stephen
>>>
>>>>>>DTMF via RTP is just another codec. IIUC PERC is agnostic to 
>>>>>>codec, so why would you be singling it out?
>>>>>
>>>>>
>>>>Choosing to treat it as "any other codec" means the MD cannot use 
>>>>DTMF to extend conference functions that it might have.  Most 
>>>>traditional MCUs do use DTMF to extend conference controls.  
>>>>Personally I don't see that as a problem for PERC, and potentially 
>>>>allowing an actor w/o the e2e key access to control conference 
>>>>functions is a bad idea.
>>>>
>>>>
>>>>generally for it's intended use of camera control.  There is at 
>>>>least one MCU that uses RFC 4573 for conference control, and that 
>>>>particular use won't work for MDs.  That's not a problem for me.
>>>>
>>>>packet lengths unless some form of padding is provided, and the use 
>>>>of marker bits also leaks some information.  RFC 4103 is old, and 
>>>>it's security considerations doesn't mention either of these.  RFC 
>>>>6562 could apply, but it's scope is limited specifically to VBR 
>>>>audio, and RFC 4103 is not that.  Stopping those leaks is not a PERC 
>>>>issue of course, but might be something that AVT should clean up.
>>>>
>>>>
>>>>text?  I don't believe PERC provides that, and it might be hard to 
>>>>do. [/SB]
>>>>
>>>>
>>>
>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 10 Apr 2017 07:28:47 -0600

> On Apr 4, 2017, at 4:22 AM, Sergio Garcia Murillo <[email-masked]> wrote:
> 
> Hi all,
> 
> Hate to ask this, but I have one more doubt when making changes to libwertc to support double. Should DTMF be also double protected or we should send it HBH?
> 
> At least on webrtc, browsers are only meant to send DTMF, not receive them, so it would make sense to end them at the SFU and not propagate it to the other participants.
> 
> Best regards
> 
> Sergio
> 

DTMF send in RTP should be treated just like any other media. There are PERC use cases where we do want DTMF to get to the far end and be E2E protected. Keep in mind PERC is meant to work with WebRTC but also with things other than WebRTC. If and endpoint wants to signal things to the MD ( like mute ), then there are much better ways than using DTMF to do that.

---

From: Stephen Botzko <[email-masked]>
Date: Mon, 10 Apr 2017 13:35:14 -0400

On Mon, Apr 10, 2017 at 9:28 AM, Cullen Jennings <[email-masked]> wrote:

> DTMF send in RTP should be treated just like any other media. There are
> PERC use cases where we do want DTMF to get to the far end and be E2E
> protected. Keep in mind PERC is meant to work with WebRTC but also with
> things other than WebRTC. If and endpoint wants to signal things to the MD
> ( like mute ), then there are much better ways than using DTMF to do that.
>
[sb]There are *always* much better ways than using DTMF for anything,
including PERC e2e.  So that sword cuts both ways.

IMO there are use cases for both e2e and h2h.  The OHB flag proposal
actually enables both, if we wanted to allow it.  Note I'm not saying we
*should* allow it, just that we *could*.  Supporting both ways in the same
implementation would be difficult to explain clearly to users.[/sb]