Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of WebRTC)

[Hadriel Kaplan <[e-mail]>]

On Nov 11, 2011, at 7:02 AM, Roman Shpount wrote:

> Well, this is a perfect example when specifying mandatory security for wrong reasons is simply being ignored. All the reactions I've seen to this so far were "this is only a SHOULD, let's disregard this for now". Getting security requirements in the standard which are too high too be practical usually produces products which disregard security completely, reaching the exactly opposite effect. I think, in this particular case, the right course of action is to use AVT tones in RTP as the rest of the industry is doing now.

I think using in-band tones in RTP for DTMF instead of 4733 would be a really bad idea.  

It's not the case that "the rest of the industry" does this.  It's true that many media-servers/PSTN-gateways *also* support in-band tones, but I don't think I've ever seen one that didn't support either RFC 2833/4733 or some SIP-based message indication method, or both.  Have you seen such?  What kind of devices were they?

The only devices I've seen which support *only* in-band tones have been some MTA endpoints and some old gateways for the inbound-direction for media coming from PSTN into SIP.  Both of those aren't a use-case for WebRTC.  WebRTC browsers need to be able to send DTMF out, but they don't need to receive DTMF; and they only need to send it out to media servers/gateways, not to far-end MTA endpoints.

Conversely, I have seen gateways which do NOT support in-band tones, and only support 2833/4733 or SIP-based message indications or both.


> Finally, (going slightly off topic here) it would probably be a good idea to make key exchange part of the initial ICE transaction. This way we can use this key exchange as an additional verification of the remote party, and reduce the number of round trips required before the media flow is established.

That's an interesting idea.  The extra round trips of DTLS-SRTP, added to those of ICE, have had me worried about clipping when the user answers the call.  It's been an advantage of SDES not to worry about that.

-hadriel