Subject: [rtcweb] Let's define the purpose of WebRTC

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 5 Nov 2011 14:35:35 +0100

Hi, in theory WebRTC is about realtime communications for the Web, but
there is interest in making it interoperable with SIP networks. So:

- Who is interested in interoperability with SIP? telcos (and me).

- Are telcos the main target of *Web*RTC? I don't think so. There are
millons of websites out there that would be interested in realtime
communications without any kind of interaction with SIP networks.
There are also other VoIP protocols.

- What does require "interoperability with SIP"? does it mean that
WebRTC should allow plain RTP and no ICE? This has been discussed many
times in this WG: Security in the media plane MUST NOT be optional, it
MUST be a MUST. So sorry, but a legacy SIP device not implementing
SRTP+ICE cannot interoperate with a WebRTC endoint. Period.

I'm the first one interested in making WebRTC interoperable with SIP,
but NOT with insecure and legacy SIP. So I assume that 99% of current
SIP devices will NOT interoperate in the media plane with a WebRTC
endpoint without the help of a smart media gateway implementing
ICE+SRTP. Neither I know whether such media gateway is feasible or
not. Sorry if not.

So IMHO this WG should clarify these points so we can move on faster.
If these points are already stated by WebRTC specs then forget this
mail please, but I still see folks asking for "legacy SIP
interoperability without requiring SRTP or ICE".

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Sat, 5 Nov 2011 09:54:44 -0400

> SRTP+ICE cannot interoperate with a WebRTC endoint. Period.

I disagree very strongly in regard to security. This is insane to require
features just for the sake of requiring them.This is not about
interoperability. It is about the fact that 99% of users will never need or
care about SRTP. They do not now for most of the web traffic. This is also
about the fact that developers will not be able to debug or troubleshoot
anything. If you get a quality problem, it would be next to impossible to
figure out what's causing it with everything encrypted. Even now, for
development, HTTPS only services allow HTTP. There are no debug tools for
the media plane except wireshark. And we are effectively taking it away.
So, why are we making this a requirement? It should not be any different
then HTTPS vs HTTP. I think it should be DTLS-SRTP with optional RTP. The
fact that RTP is allowed should be a part of the same user consent dialog
that is displayed when access to local media is allowed. If user agrees,
there is no harm to anybody, except the user.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 5 Nov 2011 15:05:37 +0100

2011/11/5 Roman Shpount <[email-masked]>:
> The fact that RTP is allowed should be a part of the same user consent
> dialog that is displayed when access to local media is allowed. If user
> agrees, there is no harm to anybody, except the user.

If the solution is to ask user consent for everything I would expect this:

Prompt 1)

------------------------------
Website http://lalala.com attemts to make an audio/video call with
you, which involves access to your microphone and webcam. Do you
accept?

  [ Yes ]     [ No ]
------------------------------

Prompt 2)

------------------------------
This audio/video call does not use encrypted media so your audio/video
could be intercepted by an attacker. Do you accept it anyway?

  [ Yes ]     [ No ]
------------------------------

Prompt 3)

------------------------------
This audio/video call does not use ICE protocol so you have no
knowledge about the real destination of the audio/video your computer
will sent. Do you accept it anyway?

  [ Yes ]     [ No ]
------------------------------

Prompt 4)

------------------------------
Do you really understand what previous questions involve? this is, are
you an expert in realtime communications?

  [ Yes ]      [ No ]
------------------------------

Prompt 5)

------------------------------
Would you like to bypass all this stuf forever and accept calls
regardless security concerns you don't understand?

  [ Yes Please !!! ]     [ No, but ask me later ]
------------------------------

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 5 Nov 2011 07:34:31 -0700

On Sat, Nov 5, 2011 at 6:54 AM, Roman Shpount <[email-masked]> wrote:
> If you get a quality problem, it would be next to impossible to
> figure out what's causing it with everything encrypted

It's actually not that bad. There are network analysis tools that can process
encrypted traffic if they are provided with the keys. They're a pretty standard
tool for debugging HTTPS. I believe wireshark can do this and I know ssldump
can.

-Ekr

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 5 Nov 2011 08:28:11 -0700

> tool for debugging HTTPS. I believe wireshark can do this and I know
ssldump

I think you can set crypto in srtp to null as well for troubleshooting

Cb

> -Ekr
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 5 Nov 2011 08:37:25 -0700

Good point. Also, of course (unless you use the SRTP header encryption
extension) the SRTP header is in the clear, so you mostly just don't get
the media itself.

-Ekr

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 5 Nov 2011 16:47:28 +0100

> extension) the SRTP header is in the clear, so you mostly just don't get

Hi, please use another thread for discussions about SRTP with no
encryption. This thread was supposed to discuss the purpose and scope
of WebRTC :)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 6 Nov 2011 03:45:41 +0000

> - Who is interested in interoperability with SIP? telcos (and me).

I think that's an exaggeration, or perhaps a simplification, or generalization - well, some X-ation anyway. :)

There is a ton of SIP in the Enterprise market, and they're not "Telcos".  Enterprises deploy a lot of web servers and web applications as well, obviously - some for the public Internet, and some for their intranet (which may happen to be through VPNs over the public Internet).

> SRTP+ICE cannot interoperate with a WebRTC endoint. Period.

I don't think one can lump SRTP together with ICE as an all-or-nothing binary choice of "security".  The two solve very different problems.  The WG may end up deciding both have to be used in the end, but the decision should be made independently.

I don't see a way to let WebRTC happen without ICE, for example, simply for the consent portion of it - we can't trust the Javascript well enough to do without it.  But supporting plaintext RTP isn't about trusting/not-trusting the Javascript - it's more akin to allowing web-applications to use HTTP vs. HTTPS.  Are we going to mandate HTTPS be used as well?

There are web applications which don't care about securing their content.  A game app, for example, might not care about secure media and might not want to use SRTP because they have to use a central media server mixer or announcement server or whatever, and don't want to take the hit for SRTP on it.  Another example is a website for creating virtual greeting cards, which might use WebRTC to record a personal greeting to go with the virtual card, and might not want to take the hit to secure media to their recording servers. (I don't know if they're popular elsewhere, but in the US these virtual greeting e-card things are popular for sending birthday/anniversary/etc. greetings, and most of them are plaintext HTTP)

-hadriel

---

From: José Luis Millán <[email-masked]>
Date: Sun, 6 Nov 2011 10:16:24 +0100

Hello you all,

> There are web applications which don't care about securing their content.  A game app, for example, might not care about secure media and might not want to use SRTP because they have to use a centr…

draft-ietf-rtcweb-overview-02 downgraded the SRTP concerns from
mandatory-to-use to mandatory-to-implement. So if it does not
downgrade anymore, a WebRTC implementation (game app, greeting cards
website..) will have to implement SRTP.

IMHO, if a web service doesn't want to take, or cannot take, the hit
for SRTP, WebRTC is not the appropriate solution for such a service.

---

From: Tim Panton <[email-masked]>
Date: Sun, 6 Nov 2011 12:05:09 +0000

> encryption. This thread was supposed to discuss the purpose and scope

"There are a number of proprietary implementations that provide direct
interactive rich communication using audio, video, collaboration,
games, etc. between two peers' web-browsers. These are not
interoperable, as they require non-standard extensions or plugins to
work. There is a desire to standardize the basis for such
communication so that interoperable communication can be established
between any compatible browsers. The goal is to enable innovation on
top of a set of basic components. One core component is to enable
real-time media like audio and video, a second is to enable data
transfer directly between clients."

Seems like time to rewrite the charter - that doesn't even nearly describe
what we have on the table at the moment.

Tim.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 6 Nov 2011 13:24:55 +0100

> what we have on the table at the moment.

Tim,
I have been unable to follow all the mail threads, but your message worries me.
Can you be a bit more specific on what you see that we have on the mentioned
table and what worries you?

Thanks,
/O

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 6 Nov 2011 14:05:55 +0100

Hi,

I totally agree with Hadriel's statement :)

...but I still care about security. However, for me the biggest issue is not whether *usage* of SRTP is mandated or not, but that I am able to use it with SDES. Yes, because of legacy interoperability :)

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Hadriel Kaplan [[email-masked]]
Sent: Sunday, November 06, 2011 5:45 AM
To: Iñaki Baz Castillo
Cc: <[email-masked]>
Subject: Re: [rtcweb] Let's define the purpose of WebRTC

-hadriel

---

From: Tim Panton <[email-masked]>
Date: Sun, 6 Nov 2011 14:01:35 +0000

> table and what worries you?

Almost all of the discussions here in the last few weeks are about interop with existing SIP 
deployments. ( forking,glare, SDP, RTP muxing) The bulk of the use-cases on which that effort is
based are also around interop with non-browser devices and channels, but the charter
never mentions legacy interop. It only talks about browser-to-browser and replacing the
myriad plugins. It also talks about being a platform for innovation, which is now a
non-goal for the group.

Iñaki asked a question as to the purpose of WebRTC, so I quoted the charter.
As I re-read it, I found that we have drifted a _long_ way from those stated goals.

On that basis, I say we have to re-evaluate something - either the charter or what we
now have. They are (to my mind) incompatible.

As a concrete example - (there are _many_ but to name a current example) - we seem to be 
on the point of dropping the SRTP requirement in order to ease interop with legacy devices.
How that squares with the charter - or indeed the ITEF's security stance I have no clue.

Personally I'd like the charter re-written to reflect the actual goals of this group. That way
those who disagree can go off an form a group that _does_ reflect this group's original
purpose and focus on the browser to browser innovation case.
If we don't - we are likely to end up with a halfway house that is bad at interop and bad 
for innovation (which is pretty much where we are now).

Tim.

Tim.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 6 Nov 2011 06:38:15 -0800

> website..) will have to implement SRTP.

Hmm... I I don't see any
reason to allow insecure calling from one WebRTC client to another.
It's a different question whether one should allow insecure calling
to legacy clients.

> for SRTP, WebRTC is not the appropriate solution for such a service.

I'm exceedingly unsympathetic to the claim that SRTP is too slow. This
is precisely the claim that was made about TLS for years, but measurements
(see Langley and Modadugu's Overclocking SSL talk at Velocity) show
that that's not really true.

-Ekr

---

From: Justin Uberti <[email-masked]>
Date: Sun, 6 Nov 2011 11:34:52 -0500

On Sun, Nov 6, 2011 at 9:38 AM, Eric Rescorla <[email-masked]> wrote:

> >> I think that's an exaggeration, or perhaps a simplification, or
> generalization - well, some X-ation anyway. :)
> >>
> >> There is a ton of SIP in the Enterprise market, and they're not
> "Telcos".  Enterprises deploy a lot of web servers and web applications as
> well, obviously - some for the public Internet, and some for their intranet
> (which may happen to be through VPNs over the public Internet).
> >>
> >>
> >> I don't think one can lump SRTP together with ICE as an all-or-nothing
> binary choice of "security".  The two solve very different problems.  The
> WG may end up deciding both have to be used in the end, but the decision
> should be made independently.
> >>
> >> I don't see a way to let WebRTC happen without ICE, for example, simply
> for the consent portion of it - we can't trust the Javascript well enough
> to do without it.  But supporting plaintext RTP isn't about
> trusting/not-trusting the Javascript - it's more akin to allowing
> web-applications to use HTTP vs. HTTPS.  Are we going to mandate HTTPS be
> used as well?
> >>
> >> There are web applications which don't care about securing their
> content.  A game app, for example, might not care about secure media and
> might not want to use SRTP because they have to use a central media server
> mixer or announcement server or whatever, and don't want to take the hit
> for SRTP on it.  Another example is a website for creating virtual greeting
> cards, which might use WebRTC to record a personal greeting to go with the
> virtual card, and might not want to take the hit to secure media to their
> recording servers. (I don't know if they're popular elsewhere, but in the
> US these virtual greeting e-card things are popular for sending
> birthday/anniversary/etc. greetings, and most of them are plaintext HTTP)
> >
Agreed. I am also unsympathetic to the claim that SRTP is too hard to
debug. Google+ Hangouts was built as SRTP-only, and this (as well as
performance) was never an issue in the construction and deployment of the
service.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 6 Nov 2011 18:42:40 +0100

> ...but I still care about security. However, for me the biggest issue is not whether *usage* of SRTP is mandated or not, but that I am able to use it with SDES. Yes, because of legacy interoperabil…
Personally, I don't care much about interoperability with a broken security model, like SDES. I still think, like I voiced before,
that we should have no option to disable SRTP. Game developers will not be hurt by it, I think you are wrong there Hadriel.
It's time to move forward and agree that security by default is a much better solution for all the use cases. I have a hard time
finding a use case where security by default, mandated by our specs, will actually hurt more than interoperability with
old SIP phones. 

The SIP market teaches me that customers will not require security. If Skype had asked customers, they would have ended
up on tabloids with headlines about neighbours listening to my calls - because customers would have said 
"Oh no, I have no secrets to hide". And that's where we will end up too, unless we take a position.

Users won't ask for security. Web hackers won't ask for security. But they will all need it and trust us to fix it.

/O

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 7 Nov 2011 01:17:50 +0000

> website..) will have to implement SRTP.

Technically, no... a mandatory-to-implement means devices complying with WebRTC RFCs (namely browsers) must implement support for it, but not have to use it for every session.  So a game app, greeting card, etc., web application could choose not to use SRTP, just like it chooses to use HTTP rather than HTTPS.  That's all I'm talking about: that difference of mandatory-to-implement vs. mandatory-to-use requirement.  

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 7 Nov 2011 03:08:23 +0000

Hey Tim,
comments inline...

On Nov 6, 2011, at 9:01 AM, Tim Panton wrote:

> deployments. ( forking,glare, SDP, RTP muxing)

RTP muxing is actually not an existing SIP thing - it's new.  SDP obviously is an existing mechanism and used in SIP, but if we're going to have a high-layer abstracted "API" anyway regardless of SIP interop, then at least SDP is an already existing/defined protocol.  Glare and forking could both be handled with purely application coding (ie, javascript), so yeah those are more of a conciliation for interop.

> The bulk of the use-cases on which that effort is

Actually, in the charter itself is a list of work the WG will perform, and item 9 says this:
      The group will consider options for interworking with legacy VoIP
      equipment.

I think the reason a lot of the email discussions have been focused on that is that it's the most contentious area of issues to solve or make decisions about.  Obviously some folks also see a reasonable use-case for interworking with legacy VoIP, but so long as non-inteworking/WebRTC-only use-cases aren't impaired by supporting interworking, what's the harm?

-hadriel

---

From: Randell Jesup <[email-masked]>
Date: Sun, 06 Nov 2011 22:14:14 -0500

> myriad plugins. It also talks about being a platform for innovation, which is now a

I respectively disagree.  While I (and others) have sat back and let a 
bunch of people argue over that, I assure you that interop has not been 
a major factor in my discussions with other stakeholders or a primary 
use-case for me.  Has interop gotten discussion?  Yes, partly due to 
many of the people arguing here, and partly due to some of those cases 
being tougher, or that interop exposes some tricky edge cases that may 
exist without interop as well.

For example, you mention forking and glare.  Well, I've given very 
non-interop cases of where forking would be useful: contacting someone 
who has 2 desktops, a notebook, a tablet, and a phone all logged into 
the service, or some of the game scenarios, or a very 
non-standard-SIP-like mesh conference using forked invites.  And glare: 
Cullen's classic example of glare is two people talking, browser to 
browser, and one saying "lets add video", and both turning it on.  No 
interop or SIP required for that to cause glare.  And RTP muxing? 
That's to avoid the startup-delay of having to ICE multiple ports (and 
the funny side-effects if they choose different paths).  Yes that does 
add some requirements to think about for interop; that's not subverting 
the charter or drifting from it.

> How that squares with the charter - or indeed the ITEF's security stance I have no clue.

People have discussed cases where SRTP either doesn't really add to the 
user's security, and if you are interfacing to the PSTN, being forced 
through a media gateway might be merely a HW/$ cost to the service, or 
it might also be a major degrader of the call quality, of the media 
gateway isn't close to either the PSTN gateway or the caller.

These are arguable cases, but for the time being, a number of use-cases 
and possible applications would want to have the option of talking to a 
PSTN gateway, even if that's not the primary use.  That makes it worth 
exploring to see if it's possible while retaining other requirements, 
and not opening the user to bid-down attacks, etc.  Thus far, we don't 
have a great solution or perhaps even a usable one.

For browser-to-browser (webrtc-to-webrtc really), there's much less (if 
any) reason to avoid SRTP.

As for SDES... I don't consider SDES to be secure, especially not in our 
threat model.  The app has access to the keys, and we don't trust the 
app.  It's more secure than no encryption, and it may be better at 
interop, but that's it.  I think I'd oppose SDES use for anything except 
interop cases.

-- 
Randell Jesup
[email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 7 Nov 2011 03:20:26 +0000

> It's a different question whether one should allow insecure calling

Agreed.

> that that's not really true.

Who said "too slow"?  There *is* an extra round-trip or two involved I presume, if we're talking DTLS-SRTP, but no I didn't mean that as a "hit".  I just meant the extra computing cycles for SRTP being a "hit".  For WebRTC-to-WebRTC I don't think that matters at all.  For WebRTC-to-media-server it might, for a free game app or greeting card app that don't care about it to begin with, and which use plaintext HTTP to begin with.

(this isn't a big deal regardless - just something to think about whether we care or not)

-hadriel

---

From: Roman Shpount <[email-masked]>
Date: Sun, 6 Nov 2011 22:36:20 -0500

> I think you can set crypto in srtp to null as well for troubleshooting
Would not that be the same as supporting RTP?
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Sun, 6 Nov 2011 22:58:46 -0500

> myriad plugins. It also talks about being a platform for innovation, which
First of all, this is not about interop. We have a fairly significant
experience regarding real-time communications, but for many reasons most of
this experience is related to SIP. Based on this, experience we know that
there are issues, such as glare, media forking, media negotiation, support
of future codecs, that need to be addressed. If we are asking about
scenarios which have not been relevant to your particular "innovative"
application, it does not mean that other users of WebRTC will not encounter
it. This is all about creating the best possible future proof system we can.

Second, the reason I raised my comment about SRTP was exactly in order to
support future applications that we are not aware about now. I do not see a
why we should mandate something without a good reason. The more control we
will give to developer, the more applications it would be possible to
build. I would strongly support required to implement, but not required to
use model for SRTP. This way SRTP is available to the application developer
but not something they must use. There are places where communications are
illegal, unless they can be intercepted by the "big brother". Things like
Skype are illegal there for this exact reason. I would not argue if this
situation is appropriate, legal, or moral, but it exists. It would be
better that WebRTC would be able to operate in environments like this.
_____________
Roman Shpount

---

From: "John Elwell" <[email-masked]>
Date: Mon, 7 Nov 2011 08:17:51 -0000

Concerning SDES, I agree its security is poor. Essentially it is a 
hop-by-hop model, because any intermediary with access to the signalling has 
access to the keys, and with the help of a media gateway can trans-key or 
map to RTP.

There are so many things one might need to do to interwork with legacy 
(demux, terminate ICE, terminate DTLS-SRTP, even transcode possibly). All 
can be done with a media gateway. Trying to avoid this for particular 
situations (e.g., finding a way of using RTP or SRTP/SDES) will not 
necessarily eliminate the need for a media gateway for other functions in 
those situations and will certainly not avoid the need for a media gateway 
in all situations. Wouldn't it be better to stick to a simple approach for 
WEB-RTC (minimal options) and say that if you want to interoperate with 
anything else you just have to use a media gateway? Applications that need 
to interoperate can choose whether they use WEB-RTC and take the hit, or 
instead can choose some other technology (such as plug-ins). In some ways 
this would be fairer. Also it is probably the only way of getting WEB-RTC 
completed in a reasonable time.

John

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 07 Nov 2011 09:51:13 +0100

On 11/07/2011 04:36 AM, Roman Shpount wrote:
>
> On Sat, Nov 5, 2011 at 11:28 AM, Cameron Byrne <[email-masked] 
> <mailto:[email-masked]>> wrote:
>

I don't think so - SRTP with null encryption would still be able to 
deliver integrity protection.

That said, in our deployment of the SRTP-based Google Talk Video and 
Hangouts services, I don't think we've ever had a critical debugging 
scenario where the lack of null crypto was a blocker.
(we don't support null crypto).

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 07 Nov 2011 10:07:14 +0100

> for SRTP, WebRTC is not the appropriate solution for such a service.
Forking this thread, since it's actually about a line in the documents....

in draft-ietf-rtcweb-overview-02, I changed this section:

5.  Data framing and securing

    SRTP [RFC3550] is used for transport of all real-time media.

    The detailed considerations for usage of functions from RTP and SRTP,
    as well as for non-media real-time data, are given in <WORKING GROUP
    DRAFT "MEDIA TRANSPORTS">.

into this section:

5.  Data framing and securing

    The format for media transport is RTP [RFC3550].  Implementation of
    SRTP [RFC3711] is required for all implementations.

    The detailed considerations for usage of functions from RTP and SRTP
    are given in [I-D.ietf-rtcweb-rtp-usage].  Key negotiation for SRTP
    is described in <MISSING>.  Transfer of data that is not in RTP
    format is described in <MISSING>.

At the moment, draft-ietf-rtcweb-rtp-usage does not contain any 
requirement on SRTP usage (the security section says "A mandatory to 
implement media security solution will be required to be picked", which 
I think is a bit weak), and the discussion at the time did not seem to 
indicate consensus that SRTP must be used always, so I decided to 
document what we seemed to have consensus on - that SRTP MUST be 
implemented.

If we have consensus to make it stronger again, I'm happy to change it back.

                   Harald

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 7 Nov 2011 11:59:23 +0100

2011/11/7 Randell Jesup <[email-masked]>:
>  I think I'd oppose SDES use for anything except interop cases.

What you say means that the web browser MUST accept SDES always, since
it won't know when it is interoperating with a non WebRTC client.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Wolfgang Beck <[email-masked]>
Date: Mon, 7 Nov 2011 13:20:03 +0100

On Mon, Nov 7, 2011 at 4:14 AM, Randell Jesup <[email-masked]> wrote:
>> [..]
> non-interop cases of where forking would be useful: contacting someone who
> has 2 desktops, a notebook, a tablet, and a phone all logged into the
> service, or some of the game scenarios, or a very non-standard-SIP-like mesh
> conference using forked invites.
Do you really need forking to achieve this? Couldn't you just return
references to those devices back to the caller
which can then decide how to call them? A redirect server instead of a
forking proxy?

Forking is a good example how interop -- with SIP or with different
RTCWEB apps -- complicates things significantly.

> And glare: Cullen's classic example of glare is two people talking, browser to browser, and one saying "lets add
> video", and both turning it on.  No interop or SIP required for that to
> cause glare.
If your service requires this function, yes, you're right. It has
nothing to do with SIP and interop.

The question is: does a JS client have to deal with glare handling if
it can exclude conflicting offers by other means. My 'click here to
speak to a human' application might never need this at all.

> And RTP muxing? That's to avoid the startup-delay of having to
> ICE multiple ports (and the funny side-effects if they choose different
> paths).  Yes that does add some requirements to think about for interop;
> that's not subverting the charter or drifting from it.
>
RTP muxing has little to with RTCWEB. If it is a good thing, SIP and
other protocols using RTP/ICE should profit from it, too.

Wolfgang Beck

---

From: Stefan Håkansson LK <[email-masked]>
Date: Mon, 7 Nov 2011 13:39:25 +0100

On 11/07/2011 04:14 AM, Randell Jesup wrote:
....

> And glare:
> interop or SIP required for that to cause glare.
I would say, if we could completely forget legacy we could also forget 
glare. We could have one offer/answer to open a connection (using ICE). 
Setting up the RTP-streams could then be separate for each end: the A 
side initiaes offer/answer to set up the streams flowing A->B and B does 
the corresponding for streams B->A, and these o/a dialogues could be 
separated. (In essence each side set's up what is in its localStreams 
array independently.) Then there would be no glare. (Not that I'm 
arguing for it)

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 7 Nov 2011 05:50:20 -0800

> Who said "too slow"?  There *is* an extra round-trip or two involved I presume, if we're talking DTLS-SRTP, but no I didn't mean that as a "hit".  I just meant the extra computing cycles for SRTP b…

Sorry, I didn't mean to put words in your mouth. Performance measurements
of HTTP versus HTTPS in modern Web environments suggest that the additional
load for HTTPS is not significant. Do you have evidence that the situation is
different for SRTP versus RTP?

-Ekr

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 07 Nov 2011 15:09:41 +0100

On 11/07/2011 02:50 PM, Eric Rescorla wrote:
> On Sun, Nov 6, 2011 at 7:20 PM, Hadriel Kaplan<[email-masked]>  wrote:
FWIW, one particularly clumsy implementation of a test of SRTP 
encryption speed that I dealt with spent nearly forty microseconds of 
(single-thread, no-hardware-acceleration) CPU time AES-encrypting an RTP 
packet - consuming nearly 0.1% of the time I had before the next packet 
arrived on that audio channel.

This, like all measurements, is false. But it convinced me that this was 
not the part of the system I needed to optimize.

---

From: Randell Jesup <[email-masked]>
Date: Mon, 07 Nov 2011 10:36:13 -0500

On 11/7/2011 7:20 AM, Wolfgang Beck wrote:
> On Mon, Nov 7, 2011 at 4:14 AM, Randell Jesup<[email-masked]>  wrote:

> which can then decide how to call them? A redirect server instead of a

So I assume instead of letting the server fork, you'd have the server 
return "you should really call these N specific sub-addresses", and have 
the client redo the call with those sub-addresses (which BTW complicates 
the security and camera/mic access model, I think).  It would then 
generate N parallel OFFERs via the server.

This generates several unwanted side-effects:

a) possible more complex security/user-agreement issues

b) at a minimum an extra round-trip for call setup if "forking" is 
needed, before any client is informed there's an incoming call.  In 
practice this may be much worse, since N parallel OFFERs will mean N ICE 
candidate harvestings in order to send out the OFFERs.

c) when one candidate is ACCEPTed, the client will be responsible for 
cancelling the OFFERs to the others (assuming it only wanted one 
conversation), or more ongoing resources used, if it wants to leave the 
option for other 'forked' destinations to answer.

d) higher bandwidth and resource use, both by the client and the server. 
  While this may seem minor, the extra energy used (and extra network 
traffic for ICE, cancelling OFFERs, etc) could actually matter for 
mobile clients, which is where all of this will likely be moving to.

There's also a timing hole opened (small) where the list returned may no 
longer be correct when the multiple OFFERs are sent - I think this, 
while real, doesn't really matter in practice.

> RTCWEB apps -- complicates things significantly.

I think letting the server fork it (parallel forking) actually is less 
complication in practice.

> speak to a human' application might never need this at all.

If there's any way both the client and the person at the other end could 
cause a re-OFFER (say if your local IP address changes??), then glare is 
always possible.  Best to simply design for it so the application 
doesn't need to, especially since most app developers will have no 
concept what glare is or why it might happen.

-- 
Randell Jesup
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Mon, 07 Nov 2011 10:40:24 -0500

> array independently.) Then there would be no glare. (Not that I'm

Even two one-way channels could have glare between an IP change at one 
end (or change in what resources it has to receive codecs, or window 
size it's displayed, etc), and the sender wanting to change something 
(even simply to go inactive/MUTE).

-- 
Randell Jesup
[email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 7 Nov 2011 15:42:14 +0000

> different for SRTP versus RTP?

Only from the DSP guys, and those would be hardware DSPs not softDSPs.  It runs them anywhere from 10-25% overhead, they say, depending on the vendor and what else their DSPs are doing at the time.

But ultimately even in software I assume it's all relative to what other work you're doing.  If you have to render a video stream on a screen and encode camera input into a codec being sent out, then my guess is SRTP overhead is a tiny factor not worth talking about.  If you're mixing multiple RTP streams as a conference server, then I assume doing SRTP for thousands of simultaneous audio RTP streams for multiple simultaneous conferences becomes noticeable.  Or at least so they seem to claim - I don't know since I don't build a media server (hardware SBCs often offload SRTP onto dedicated hardware).  One large software company even created their own proprietary packet format for SRTP that they claimed was done for improving performance/scalability, so I assume it has some impact they don't want their customers to incur.

-hadriel

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 7 Nov 2011 16:50:18 +0100

> which can then decide how to call them? A redirect server instead of a

That's a limitation rather than a simplification, and would make lot
of scenarios just harder. Don't think just in SIP. Any future *pure*
WebRTC scenario could desire to fork a call into multiple N
destinations without making the *JavaScript* client code to deal with
N different sessions.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Randell Jesup <[email-masked]>
Date: Mon, 07 Nov 2011 10:54:35 -0500

> not the part of the system I needed to optimize.

Not that I disagree about SRTP and overhead(!), but I will note that 
video can easily use 30-100x the bandwidth (and typically 30-100x the 
encryption/decryption overhead) of audio, which could approach 3-10% 
perhaps in a 'clumsy implementation', and you need to consider decode 
(similar overhead) and multiple streams.  It may not be a lot on it's 
own, but the amount of CPU left over after audio/video 
encode/decode/AEC/processing/etc may not be a lot, and on many devices 
that may limit of the client's ability to process calls at good frame 
rates and resolutions, forcing it down the the next-lower resolution 
shelf, especially on clients with minimal HW assist and on mobile.

I agree encryption/decryption overhead should not be a significant 
factor in the discussion of SRTP.  I would like to see estimates of 
encrypt/decrypt speed per byte on mobile devices, though.

-- 
Randell Jesup
[email-masked]

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 7 Nov 2011 11:16:03 -0500

Eric Rescorla wrote:

> extension) the SRTP header is in the clear, so you mostly just don't get the media itself.

The extension (assuming you're talking about draft-ietf-avtcore-srtp-encrypted-header-ext) is header extension encryption, not a header encryption extension ... the base RTP header remains in the clear in SRTP, even with this draft. 

SRTP forms its per-packet IVs based on the SSRC and sequence number, so those fundamentally have to be sent in the clear.  I suppose in theory you could encrypt some of the other fields of the RTP header, but I don't see much point in it. (At some point, if things are this sensitive, you're better off just using IPSec.)

-- 
Jonathan Lennox
[email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 07 Nov 2011 17:27:35 +0100

On 11/07/2011 04:36 PM, Randell Jesup wrote:
> return "you should really call these N specific sub-addresses", and 
> have the client redo the call with those sub-addresses (which BTW 
> complicates the security and camera/mic access model, I think).  It 
> would then generate N parallel OFFERs via the server.
If we were doing a greenfield application, I'd let the server tell all 
the possible endpoints that they should set up a connection to the 
original caller, and forget about the caller calling anyone.

The difference between caller and callee is a question of your level of 
abstraction.....

---

From: Wolfgang Beck <[email-masked]>
Date: Mon, 7 Nov 2011 17:53:04 +0100

On Mon, Nov 7, 2011 at 5:27 PM, Harald Alvestrand <[email-masked]> wrote:
[on SIP-style forking]
> If we were doing a greenfield application, I'd let the server tell all the
> possible endpoints that they should set up a connection to the original
> caller, and forget about the caller calling anyone.
>

That's the kind of innovative thinking I thought RTCWEB was all about.

And this forking discussion is a good example how the requirement to
have interop between different RTCWEB apps and/or SIP is holding us
back. Ditch the trapezoid and do greenfield.

Wolfgang Beck

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 7 Nov 2011 18:34:52 +0100

> The difference between caller and callee is a question of your level of

Of course that would be a possible scenario, but such scenario assumes
that the logic is in the webserver and clients are dumb. There is no
problem with that, of course. But I hope I must not assume that the JS
is dumb for all the possible WebRTC scenarios. I do need the concept
of "caller" and "callee".

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Randell Jesup <[email-masked]>
Date: Mon, 07 Nov 2011 12:35:13 -0500

On 11/7/2011 11:53 AM, Wolfgang Beck wrote:
> On Mon, Nov 7, 2011 at 5:27 PM, Harald Alvestrand<[email-masked]>  wrote:
> [on SIP-style forking]

This has nothing to do with trapezoids.  This is something I believe we 
need even if there was an absolute block on SIP interop.

And I disagree with Harald here; telling the clients they should open 
connections to the "caller" is exactly what parallel forking by the 
server does.  It tells them "here's the offer and ICE candidates, open a 
connection to the "caller" and complete negotiation."  It'd be silly not 
to include the OFFER in the message to the "callee's", since we have to 
send them the ICE candidates anyways - plus, the "callee's" may need 
that info for alerting, etc, and not providing it would add more 
round-trips.  Never forget that even half-round-trips can be PAINFUL to 
some applications!  And don't forget that this might get used on links 
that bounce off a satellite (or two!), or transit low-bandwidth wireless 
networks or mesh networks, etc.  Now there's RTT... ;-)

Now, the "caller" may have taken the first ACCEPT, or it might run them 
parallel until a final accept on one, or it might keep all the options 
open for the entire "call" (which doesn't map super-well to SIP, note, 
though it can be emulated in SIP).  So the "caller" may decline the 
ANSWERs or final ANSWERS (ACCEPTs) from any of the forked "callees". 
That's entirely up to the app.

-- 
Randell Jesup
[email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 07 Nov 2011 20:33:21 +0100

> That's the kind of innovative thinking I thought RTCWEB was all about.
It's also something that is eminently doable with the currently proposed 
API.

---

From: Wolfgang Beck <[email-masked]>
Date: Tue, 8 Nov 2011 10:43:10 +0100

[..]
> connections to the "caller" is exactly what parallel forking by the server
> does.  It tells them "here's the offer and ICE candidates, open a connection
> to the "caller" and complete negotiation."  It'd be silly not to include the
> OFFER in the message to the "callee's", since we have to send them the ICE
> candidates anyways - plus, the "callee's" may need that info for alerting,
> etc, and not providing it would add more round-trips.  Never forget that
> even half-round-trips can be PAINFUL to some applications!  And don't forget
> that this might get used on links that bounce off a satellite (or two!), or
> transit low-bandwidth wireless networks or mesh networks, etc.  Now there's
> RTT... ;-)
>
If you are on satellite links, the signaling round trip time is not
your most pressing problem.

Is forking really essential or is it just a way to optimize call setup
time under certain conditions?
Has forking still an advantage if you want to do multiple early media?

[suppressing a remark how overlap dialing could speed up call setup
times in some interop scenarios, too]

Wolfgang Beck

---

From: Ravindran Parthasarathi <[email-masked]>
Date: Tue, 8 Nov 2011 14:30:06 +0000

I agree with Hadriel that it is not required to mandate SRTP for WebRTC. My reasoning are as follows:

1) Security could be in the lower layer itself (IPsec, VPN, private MPLS cloud). For Enterprise-only-WebRTC application (no federation & no interop), there is no need of security by specific application like WebRTC as it is ensured in the infrastructure. WebRTC security will be duplicated for these infrastructure and may leads double encryption unnecessarily.

2) Being in India, I'm interested in avoiding Government restriction on WebRTC proposal (Thanks to Tim for pointing this). I may not surprise to see that WebRTC mechanism is banned in India because intelligent agency struggles to break the key in each terrorist WebRTC site. (http://www.pcworld.com/businesscenter/article/235639/india_wants_to_intercept_skype_google_communications.html)

In case there is no use case to illustrate in RTCWeb draft, let us discuss in detail.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Hadriel Kaplan
>Sent: Monday, November 07, 2011 9:12 PM
>To: Eric Rescorla
>Cc: <[email-masked]>
>>> Who said "too slow"?  There *is* an extra round-trip or two involved
>I presume, if we're talking DTLS-SRTP, but no I didn't mean that as a
>"hit".  I just meant the extra computing cycles for SRTP being a "hit".
>For WebRTC-to-WebRTC I don't think that matters at all.  For WebRTC-to-
>media-server it might, for a free game app or greeting card app that
>don't care about it to begin with, and which use plaintext HTTP to begin
>with.
>Only from the DSP guys, and those would be hardware DSPs not softDSPs.
>It runs them anywhere from 10-25% overhead, they say, depending on the
>vendor and what else their DSPs are doing at the time.
>
>But ultimately even in software I assume it's all relative to what other
>work you're doing.  If you have to render a video stream on a screen and
>encode camera input into a codec being sent out, then my guess is SRTP
>overhead is a tiny factor not worth talking about.  If you're mixing
>multiple RTP streams as a conference server, then I assume doing SRTP
>for thousands of simultaneous audio RTP streams for multiple
>simultaneous conferences becomes noticeable.  Or at least so they seem
>to claim - I don't know since I don't build a media server (hardware
>SBCs often offload SRTP onto dedicated hardware).  One large software
>company even created their own proprietary packet format for SRTP that
>they claimed was done for improving performance/scalability, so I assume
>it has some impact they don't want their customers to incur.
>
>-hadriel
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 8 Nov 2011 15:58:26 +0100

> 1) Security could be in the lower layer itself (IPsec, VPN, private MPLS cloud). For Enterprise-only-WebRTC application (no federation & no interop), there is no need of security by specific applic…
For me this is not a valid objection. You can not ask the customer to try to find out if they are using the web browser in a secure or in an insecure 
network... That paradigm will just fail.

> 2) Being in India, I'm interested in avoiding Government restriction on WebRTC proposal (Thanks to Tim for pointing this). I may not surprise to see that WebRTC mechanism is banned in India because…
That is an interesting objection. I don't think SRTP by default is the problem here. In the case where you need lawful interception in the application,
the server needs to route the calls through an RTCweb b2b media server.

/O
>> it has some impact they don't want their customers to incur.

---
* Olle E Johansson - [email-masked]
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 8 Nov 2011 16:19:27 +0100

> document what we seemed to have consensus on - that SRTP MUST be 

Yes, we haven't spent much time on the security consideration section
yet. "A mandatory to implement media security solution will be required
to be picked" is pointer at this WG not the implementor.

I would also point at our Charter that in its last paragraph says:
"The products of the working group will support security and keying as
required by BCP 61"

If you haven't read BCP 61 you probably should. It is basically says two
things. IETF should pick strong security and it shall be MANDATORY to
IMPLEMENT. I at least as chair will ensure that we have fulfilled this.
And that means for RTP not only encryption and integrity protection,
probably SRTP, but also a keying method.

Yes, we (authors of draft-ietf-rtcweb-rtp-usage) will write that SRTP is
a MUST implement as soon as we have that consensus established. But we
will need a keying scheme also and determine where it should be documented.

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: Cullen Jennings <[email-masked]>
Date: Tue, 8 Nov 2011 08:59:06 -0700

> the server needs to route the calls through an RTCweb b2b media server.

I think the situation in India is a taxiation not encryption issue. Partha and I can do VoIP between Canada and India fully encrypted no problem - in fact we have a dial plan set up specifically so I can do that with him. The issue is a taxation issue. If we want to be able to connect that voip server to the PSTN in a way that it becomes what the regulators in India consider a telephone service, then we need permission to effectively be an indian telco. Right now I can make a full SRTP encrypted conversation with between my IP phones and Partha's but I don't think Partha can use his IP phone to access one the the PSTN GWs outside India. 

Anyways, I will remind people of RAVEN http://www.rfc-editor.org/rfc/rfc2804.txt

---

From: Roman Shpount <[email-masked]>
Date: Tue, 8 Nov 2011 11:01:24 -0500

On Tue, Nov 8, 2011 at 9:58 AM, Olle E. Johansson <[email-masked]> wrote:

>
> That is an interesting objection. I don't think SRTP by default is the
> problem here. In the case where you need lawful interception in the
> application,
SRTP is exactly what is the problem here. Do not confuse this with lawful
intercept in the application. This is about encrypted communications being
illegal in some places. If your web site is using encryption or cannot be
accessed without encryption it would be blocked. As an example we are all
familiar with, think about the key length restrictions TLS used to have due
to US export regulations. This has been lifted, but there are numerous
regulations in other countries that prohibit encryption at all, across the
borders, or from certain institutions (like prisons).

I am not arguing that we should not include SRTP. In fact I think we must,
but it should be possible to turn it off.
______________
Roman Shpount

---

From: Randell Jesup <[email-masked]>
Date: Tue, 08 Nov 2011 11:42:09 -0500

On 11/8/2011 4:43 AM, Wolfgang Beck wrote:
> On Mon, Nov 7, 2011 at 6:35 PM, Randell Jesup<[email-masked]>  wrote:

Yes, but people do talk over them, and may do other "real-time" things 
over them.  Sometimes that's simply the only option.  Even my Uncle in 
Virginia "horse country" (= $$$$$) can't get anything better than 
dial-up or satellite internet, because houses are so far apart and far 
from telco office.  And then there are people/soldiers/etc in 3rd-world 
countries or disaster relief efforts, etc.

> time under certain conditions?

I think in most cases you can set up the calls with other methods of 
varying complexity and delays.  Hard to be sure that all uses would be 
covered by that, and some might involve extra consents be generated to 
the user, or some method of tying the OFFERs together, and I'm not sure 
that can easily be done if we don't trust the JS code.  (though it might 
not be a real concern - we haven't looked at this re: security/privacy yet).

> Has forking still an advantage if you want to do multiple early media?

I suspect forking is an advantage here, but haven't analyzed it.

-- 
Randell Jesup
[email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 08 Nov 2011 23:28:05 +0100

Changing the subject again to mention SRTP....

On 11/08/2011 03:30 PM, Ravindran Parthasarathi wrote:
> 1) Security could be in the lower layer itself (IPsec, VPN, private MPLS cloud). For Enterprise-only-WebRTC application (no federation&  no interop), there is no need of security by specific application like WebRTC as it is ensured in the infrastructure. WebRTC security will be duplicated for these infrastructure and may leads double encryption unnecessarily.
This argument makes some sense.
> 2) Being in India, I'm interested in avoiding Government restriction on WebRTC proposal (Thanks to Tim for pointing this). I may not surprise to see that WebRTC mechanism is banned in India because…
This argument is contrary to stated IETF policy (RFC 2804).

I recommend the RFC for background reading.
>> Cc:<[email-masked]>

---

From: Ravindran Parthasarathi <[email-masked]>
Date: Wed, 9 Nov 2011 01:21:46 +0000

Thanks to Harald/Cullen for pointing out RFC 2804. I take back my #2 comment based on RFC 2804 wiretapping policy. 

I wish to clarify why I gave this comment before closing on #2:

It is the common practice in India to buy computer to talk/chat with the relatives who are outside India by using Skype/Gtalk/Yahoo (avoiding International subscriber dialing charges). Of course, Cell phone is more popular than Computer and cheap (~$100) Wi-Fi enabled (Android) Smartphones are available in market. WebRTC will bring the new innovative way of communicating using Smartphone (like free WebRTC session to street provisional store). Browser in Smartphone is the platform for making outgoing session towards provisional store. I really don't want these kind of WebRTC service are forbidden by Government laws unnecessarily due to security (SRTP) reasons. 

>From: Harald Alvestrand [mailto:[email-masked]]
>Sent: Wednesday, November 09, 2011 3:58 AM
>To: Ravindran Parthasarathi
>Cc: Hadriel Kaplan; Eric Rescorla; <[email-masked]>
>Subject: SRTP requirement - wiretapping (Re: [rtcweb] Let's define the
>purpose of WebRTC)
>
>> 1) Security could be in the lower layer itself (IPsec, VPN, private
>MPLS cloud). For Enterprise-only-WebRTC application (no federation&  no
>interop), there is no need of security by specific application like
>WebRTC as it is ensured in the infrastructure. WebRTC security will be
>duplicated for these infrastructure and may leads double encryption
>unnecessarily.
>> 2) Being in India, I'm interested in avoiding Government restriction
>on WebRTC proposal (Thanks to Tim for pointing this). I may not surprise
>to see that WebRTC mechanism is banned in India because intelligent
>agency struggles to break the key in each terrorist WebRTC site.
>(http://www.pcworld.com/businesscenter/article/235639/india_wants_to_int
>ercept_skype_google_communications.html)
>>>> On Sun, Nov 6, 2011 at 7:20 PM, Hadriel
>Kaplan<[email-masked]>
>>> wrote:

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 8 Nov 2011 17:41:44 -0800

[BA]  If the concern is that we will make RTCWEB soooo secure that wiretapping would be "too difficult" even for national governments with lots of resources, that is what I'd call a "high quality problem".   Reading Eric's draft, I would not say that the available security solutions are soooo advanced at the moment that this is a practical concern.  Even if we were to mandate a "heap o' crypto" (e.g. SRTP, DTLS/SRTP, PKI, etc.) the chances are excellent that it would not be deployed, would be contravened by disreputable CAs, or would not be understood well enough by users to avoid misfortunes on a regular basis.   What *does* worry me is that "wiretapping" in RTCWEB would be so easy that any script kiddie could do it, and that browser-based surveillance could become an everyday occurrence.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 8 Nov 2011 17:50:35 -0800

[BA]  If the concern is that we will make RTCWEB soooo secure that browser-based surveillance would be "too difficult" even for national governments with lots of resources, that is what I'd call a "high quality problem".  
 
Reading Eric's draft, I would not say that the available security solutions are soooo advanced at the moment that this is a practical concern.  Even if we were to mandate a "heap o' crypto" (e.g. SRTP, DTLS/SRTP, PKI, etc.) the chances are excellent that it would not be deployed, would be contravened by disreputable CAs, or would not be understood well enough by users to avoid misfortunes on a regular basis.  
 
What *does* worry me is that surveillance in RTCWEB would be so easy that any script kiddie could do it, and that it could become an everyday occurrence.

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 8 Nov 2011 18:37:22 -0800

On Nov 8, 2011 5:21 PM, "Ravindran Parthasarathi" <[email-masked]>
wrote:
>
> Thanks to Harald/Cullen for pointing out RFC 2804. I take back my #2
comment based on RFC 2804 wiretapping policy.
> It is the common practice in India to buy computer to talk/chat with the
relatives who are outside India by using Skype/Gtalk/Yahoo (avoiding
International subscriber dialing charges). Of course, Cell phone is more
popular than Computer and cheap (~$100) Wi-Fi enabled (Android) Smartphones
are available in market. WebRTC will bring the new innovative way of
communicating using Smartphone (like free WebRTC session to street
provisional store). Browser in Smartphone is the platform for making
outgoing session towards provisional store. I really don't want these kind
of WebRTC service are forbidden by Government laws unnecessarily due to
security (SRTP) reasons.

Getting into murky waters here.

I believe the ietf values privacy and I would like srtp to be mandatory
since I value privacy.

If not supporting privacy is a requirement for your government, then
perhaps webrtc is not for you.

Cb

---

From: Ravindran Parthasarathi <[email-masked]>
Date: Wed, 9 Nov 2011 02:50:37 +0000

Cameron,

I guess that we are in the same w.r.t IETF privacy policy and it is main reason, I take back my comment #2. But, Please look into comment #1 for Enterprise WebRTC application wherein SRTP is not required to be mandated.

> >duplicated for these infrastructure and may leads double encryption

Thanks
Partha

From: Cameron Byrne [mailto:[email-masked]]
Sent: Wednesday, November 09, 2011 8:07 AM
To: Ravindran Parthasarathi
Cc: &lt,[email-masked]&gt,
Subject: Re: [rtcweb] SRTP requirement - wiretapping (Re: Let's define the purpose of WebRTC)

I believe the ietf values privacy and I would like srtp to be mandatory since I value privacy.

If not supporting privacy is a requirement for your government, then perhaps webrtc is not for you.

Cb

> >From: Harald Alvestrand [mailto:[email-masked]<mailto:[email-masked]>]
> >Cc: Hadriel Kaplan; Eric Rescorla; <[email-masked]<mailto:[email-masked]>>
> >>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> >Behalf
> >>> Of Hadriel Kaplan
> >>> Cc:<[email-masked]<mailto:[email-masked]>>
> >Kaplan<[email-masked]<mailto:[email-masked]>>
> >>> wrote:
> >>> [email-masked]<mailto:[email-masked]>
> >> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Ravindran Parthasarathi <[email-masked]>
Date: Wed, 9 Nov 2011 02:58:10 +0000

Cullen,

As I mentioned in http://www.ietf.org/mail-archive/web/rtcweb/current/msg02674.html, below comment #2 is not valid in IETF. 

But I'm interested in your opinion as Enterprise UC expert on my 1st comment:

"1) Security could be in the lower layer itself (IPsec, VPN, private MPLS cloud). For Enterprise-only-WebRTC application (no federation & no interop), there is no need of security for specific application like WebRTC as it is ensured in the infrastructure. WebRTC security will be duplicated for these infrastructure and may lead to double encryption unnecessarily."

Thanks
Partha

>From: Cullen Jennings [mailto:[email-masked]]
>Sent: Tuesday, November 08, 2011 9:29 PM
>To: Olle E. Johansson
>Cc: Ravindran Parthasarathi; <[email-masked]>
>I think the situation in India is a taxiation not encryption issue.
>Partha and I can do VoIP between Canada and India fully encrypted no
>problem - in fact we have a dial plan set up specifically so I can do
>that with him. The issue is a taxation issue. If we want to be able to
>connect that voip server to the PSTN in a way that it becomes what the
>regulators in India consider a telephone service, then we need
>permission to effectively be an indian telco. Right now I can make a
>full SRTP encrypted conversation with between my IP phones and Partha's
>but I don't think Partha can use his IP phone to access one the the PSTN
>GWs outside India.
>

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 8 Nov 2011 19:27:34 -0800

On Nov 8, 2011 6:50 PM, "Ravindran Parthasarathi" <[email-masked]>
wrote:
>
> Cameron,
>
>
>
> I guess that we are in the same w.r.t IETF privacy policy and it is main
reason, I take back my comment #2. But, Please look into comment #1 for
Enterprise WebRTC application wherein SRTP is not required to be mandated.
> > >duplicated for these infrastructure and may leads double encryption

I don't believe we can assume other crypto measures are in place

Bob and Alice work for Toobigtofail Inc. They are on the same LAN segment
and using webrtc to communicate about making a large investment. On that
same LAN segment there is a compromised host intercepting all traffic (it
did some arp spoofing or something like that )

No problem here since Bob and Alice are using srtp.

If they did not, the financial info would have been exposed

Cb
> > It is the common practice in India to buy computer to talk/chat with
the relatives who are outside India by using Skype/Gtalk/Yahoo (avoiding
since I value privacy.
> > >(
http://www.pcworld.com/businesscenter/article/235639/india_wants_to_int

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 9 Nov 2011 09:12:22 +0530

|"1) Security could be in the lower layer itself 
|(IPsec, VPN, private MPLS cloud). For Enterprise-only-
|WebRTC application (no federation & no interop), 
|there is no need of security for specific application
|like WebRTC as it is ensured in the infrastructure.

One of the primary deployments for SRTP I've come across is actually
within the enterprise -- financial institutions and defense
establishments concerned about eavesdropping within their organization.
The fact that the WAN connection is secured using IPSec VPN or a private
leased line isn't good enough for such deployments.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ravindran Parthasarathi
|Sent: Wednesday, November 09, 2011 8:28 AM
|To: Cullen Jennings (fluffy); Olle E. Johansson
|Cc: <[email-masked]>
|Subject: Re: [rtcweb] Let's define the purpose of WebRTC
|
|Cullen,
|
|As I mentioned in
http://www.ietf.org/mail-archive/web/rtcweb/current/msg02674.html, below
comment #2
|is not valid in IETF.
|
|But I'm interested in your opinion as Enterprise UC expert on my 1st
comment:
|
|"1) Security could be in the lower layer itself (IPsec, VPN, private
MPLS cloud). For Enterprise-only-
|WebRTC application (no federation & no interop), there is no need of
security for specific application
|like WebRTC as it is ensured in the infrastructure. WebRTC security
will be duplicated for these
|infrastructure and may lead to double encryption unnecessarily."
|
|Thanks
|Partha
|
|>-----Original Message-----
|>From: Cullen Jennings [mailto:[email-masked]]
|>Sent: Tuesday, November 08, 2011 9:29 PM
|>To: Olle E. Johansson
|>Cc: Ravindran Parthasarathi; <[email-masked]>
|>Subject: Re: [rtcweb] Let's define the purpose of WebRTC
|>
|>
|>On Nov 8, 2011, at 7:58 AM, Olle E. Johansson wrote:
|>
|>>>
|>>> 2) Being in India, I'm interested in avoiding Government
restriction
|>on WebRTC proposal (Thanks to Tim for pointing this). I may not
surprise
|>to see that WebRTC mechanism is banned in India because intelligent
|>agency struggles to break the key in each terrorist WebRTC site.
|>(http://www.pcworld.com/businesscenter/article/235639/india_wants_to_i
nt
|>ercept_skype_google_communications.html)
|>> That is an interesting objection. I don't think SRTP by default is
the
|>problem here. In the case where you need lawful interception in the
|>application,
|>> the server needs to route the calls through an RTCweb b2b media
|>server.
|>
|>I think the situation in India is a taxiation not encryption issue.
|>Partha and I can do VoIP between Canada and India fully encrypted no
|>problem - in fact we have a dial plan set up specifically so I can do
|>that with him. The issue is a taxation issue. If we want to be able to
|>connect that voip server to the PSTN in a way that it becomes what the
|>regulators in India consider a telephone service, then we need
|>permission to effectively be an indian telco. Right now I can make a
|>full SRTP encrypted conversation with between my IP phones and
Partha's
|>but I don't think Partha can use his IP phone to access one the the
PSTN
|>GWs outside India.
|>
|>Anyways, I will remind people of RAVEN http://www.rfc-
|>editor.org/rfc/rfc2804.txt
|>
|
|_______________________________________________
|rtcweb mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Ravindran Parthasarathi <[email-masked]>
Date: Wed, 9 Nov 2011 06:24:08 +0000

Hi Muthu,

I agree with you that Defense & Financial Enterprise customer mandates for security mechanism in media path but it is not mandated for rest of the Enterprise customer. The argument here is whether it is "mandatory to implement" vs "mandatory to use". I agree that it is mandatory to implement in browser but it is not required to be mandatory to use by all the applications. Hope you agree with me.

Thanks
Partha

>From: Muthu Arul Mozhi Perumal (mperumal) [mailto:[email-masked]]
>Sent: Wednesday, November 09, 2011 9:12 AM
>To: Ravindran Parthasarathi; Cullen Jennings (fluffy); Olle E. Johansson
>Cc: [email-masked]
>Subject: RE: [rtcweb] Let's define the purpose of WebRTC
>

---

From: "Avasarala, Ranjit" <[email-masked]>
Date: Wed, 9 Nov 2011 14:33:36 +0800

Hi Partha

I feel including all kinds of security mechanisms like SRTP, TLS, etc in browser would make the browser very bulky. It would be better to provide a mechanism in the signaling protocol that browser supports to negotiate the desired security mechanism (depending on application requirement) and then use that mechanism (which is part of the system).

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ravindran Parthasarathi
Sent: Wednesday, November 09, 2011 11:54 AM
To: Muthu Arul Mozhi Perumal (mperumal); Cullen Jennings (fluffy); Olle E. Johansson
Cc: [email-masked]
Subject: Re: [rtcweb] Let's define the purpose of WebRTC

Hi Muthu,

Thanks
Partha

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 09 Nov 2011 08:02:11 +0100

> I feel including all kinds of security mechanisms like SRTP, TLS, etc in browser would make the browser very bulky. It would be better to provide a mechanism in the signaling protocol that browser…
The bulk of the browser is not reduced by a single byte by not using 
crypto functions that are present.

Not having crypto functions available would contravene the "MUST 
implement SRTP" mandate.
(btw, the code bulk of SRTP is minuscule compared to stuff like CSS3).

             Harald

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 9 Nov 2011 10:34:39 +0100

2011/11/9 Avasarala, Ranjit <[email-masked]>:
> I feel including all kinds of security mechanisms like SRTP, TLS, etc in browser would make the browser very bulky.

Including TLS in a browser makes it bulky? Then we must discourage
HTTPS usage, right?
In the other side, have you really measured how much expensive SRTP
is? it's not at all.

> It would be better to provide a mechanism in the signaling protocol that browser supports to negotiate the desired security mechanism (depending on application requirement) and then use that mechanism (which is part of the system).

The "application" is untrusted by nature, and we don't want to make
the end-user to decide whether to trust it or not. Explained many
times in this maillist.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 9 Nov 2011 10:42:01 +0100

> In the other side, have you really measured how much expensive SRTP
This kind of argument is just a no-op. We need to be able to move forward and as Eric has said on this list, these arguments against encryption is no longer valid.
You could use this against HTTP clients in SIP (SIP identity) and the whole ICE engine too. Moore's law is always helping :-)

> the end-user to decide whether to trust it or not. Explained many

Agree, we have explained this a number of times. If we leave this up to the web developers and users, we'll end up in trouble.

/O

---

From: "Avasarala, Ranjit" <[email-masked]>
Date: Wed, 9 Nov 2011 17:45:07 +0800

Ok so any consensus s far on which signaling would be used for negotiating these parameters - SIP/Jingle/etc..

Regards
Ranjit

-----Original Message-----
From: Olle E. Johansson [mailto:[email-masked]] 
Sent: Wednesday, November 09, 2011 3:12 PM
To: Iñaki Baz Castillo
Cc: Avasarala, Ranjit; Ravindran Parthasarathi; Muthu Arul Mozhi Perumal (mperumal); Cullen Jennings (fluffy); [email-masked]
Subject: Re: [rtcweb] Let's define the purpose of WebRTC

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 9 Nov 2011 10:50:23 +0100

> Ok so any consensus s far on which signaling would be used for negotiating these parameters - SIP/Jingle/etc..
I would advice you kindly to go through the mail archives. The consensus seems to be "no default signaling" after a very long and intensive discussion.

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 9 Nov 2011 10:57:46 +0100

> Ok so any consensus s far on which signaling would be used for negotiating these parameters - SIP/Jingle/etc..

No one. Or anyone. Just choose or design it (it must be a protocol on
top of HTTP or WebSocket, the protocols JavaScript can deal with).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Ravindran Parthasarathi <[email-masked]>
Date: Wed, 9 Nov 2011 10:41:12 +0000

I agree that there is no need of negotiation for security mechanism.

I'll reply to "no standard signaling" protocol in another mail thread as part of comment to ROAP draft as request by Ted (Chair) to track WebRTC signaling related stuff.  

Thanks
Partha

>Sent: Wednesday, November 09, 2011 3:20 PM
>To: Avasarala, Ranjit
>Cc: Iñaki Baz Castillo; Ravindran Parthasarathi; Muthu Arul Mozhi
>Perumal (mperumal); Cullen Jennings (fluffy); [email-masked]
>> Ok so any consensus s far on which signaling would be used for
>negotiating these parameters - SIP/Jingle/etc..
>>
>I would advice you kindly to go through the mail archives. The consensus
>seems to be "no default signaling" after a very long and intensive
>discussion.
>
>/O

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 9 Nov 2011 16:27:28 +0530

|The "application" is untrusted by nature, and we don't want 
|to make the end-user to decide whether to trust it or not. 
|Explained many times in this maillist.

I am thinking we could burn SRTP into the browser such that the decision of whether or not to use SRTP vests solely with the browser. If a WebRTC browser is exchanging media with another WebRTC browser they always do SRTP/SRTCP. If either side isn't WebRTC compliant they end up with RTP/RTCP. This way we don't need to trust the JS, instead trust only the browser. We can also interoperate with legacy devices without taxing them.

Muthu

|-----Original Message-----
|From: Iñaki Baz Castillo [mailto:[email-masked]]
|Sent: Wednesday, November 09, 2011 3:05 PM
|To: Avasarala, Ranjit
|Cc: Ravindran Parthasarathi; Muthu Arul Mozhi Perumal (mperumal); Cullen Jennings (fluffy); Olle E.
|Johansson; [email-masked]
|Subject: Re: [rtcweb] Let's define the purpose of WebRTC
|
|2011/11/9 Avasarala, Ranjit <[email-masked]>:
|> I feel including all kinds of security mechanisms like SRTP, TLS, etc in browser would make the
|browser very bulky.
|
|Including TLS in a browser makes it bulky? Then we must discourage
|HTTPS usage, right?
|In the other side, have you really measured how much expensive SRTP
|is? it's not at all.
|
|
|> It would be better to provide a mechanism in the signaling protocol that browser supports to
|negotiate the desired security mechanism (depending on application requirement) and then use that
|mechanism (which is part of the system).
|
|The "application" is untrusted by nature, and we don't want to make
|the end-user to decide whether to trust it or not. Explained many
|times in this maillist.
|
|--
|Iñaki Baz Castillo
|<[email-masked]>

---

From: Ravindran Parthasarathi <[email-masked]>
Date: Wed, 9 Nov 2011 11:19:05 +0000

Agree with Roman. I'm considering your statement as "mandate to implement" SRTP.

From: Roman Shpount [mailto:[email-masked]]
Sent: Tuesday, November 08, 2011 9:31 PM
To: Olle E. Johansson
Cc: Ravindran Parthasarathi; <[email-masked]>
Subject: Re: [rtcweb] Let's define the purpose of WebRTC

On Tue, Nov 8, 2011 at 9:58 AM, Olle E. Johansson <[email-masked]<mailto:[email-masked]>> wrote:

SRTP is exactly what is the problem here. Do not confuse this with lawful intercept in the application. This is about encrypted communications being illegal in some places. If your web site is using encryption or cannot be accessed without encryption it would be blocked. As an example we are all familiar with, think about the key length restrictions TLS used to have due to US export regulations. This has been lifted, but there are numerous regulations in other countries that prohibit encryption at all, across the borders, or from certain institutions (like prisons).

I am not arguing that we should not include SRTP. In fact I think we must, but it should be possible to turn it off.
______________
Roman Shpount

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 9 Nov 2011 12:23:41 +0100

> I am thinking we could burn SRTP into the browser such that the decision of whether or not to use SRTP vests solely with the browser. If a WebRTC browser is exchanging media with another WebRTC bro…

That opens up for downgrade attacks and put a lot of trust on the web browser UI to show what happens and on the users to understand what the web browser UA is trying to tell them.

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 9 Nov 2011 12:58:23 +0100

2011/11/9 Muthu Arul Mozhi Perumal (mperumal) <[email-masked]>:
> I am thinking we could burn SRTP into the browser such that the decision of whether or not to use SRTP vests solely with the browser.

The "browser" cannot decide that. Probably you mean the user, that
person that in 99.999% of cases does not know what "encryption" or
"SRTP" is, and in 85% of cases does not matter about security.

> If a WebRTC browser is exchanging media with another WebRTC browser they always do SRTP/SRTCP.

The browser has NO way to determine whether it's exchanging media with
another browser or not. And what you state is that, in case the peer
does not annouce support for SRTP then the browser should downgrade
security to plain RTP. The user (web visitor) has no way to know
whether the WebRTC application will contact a WebRTC browser or
another device at the media plane.

> If either side isn't WebRTC compliant they end up with RTP/RTCP.

So no security. Bad.

> This way we don't need to trust the JS, instead trust only the browser.

You mean the user.

> We can also interoperate with legacy devices without taxing them.

Sorry, but WebRTC is about "realtime communications for the Web",
rather than "SIP business coming to the Web". SIP uses RTP, including
RFC's about SRTP. If you want SIP interoperability with a WebRTC
device, then make your work as vendor and add security to your SIP
devices rather than asking no-security for WebRTC.

Please, take a look to XMPP/Jingle !!  They implement SRTP and ICE
from the beginning!! *Do* your homeworks as SIP vendor.

This is a problem of SIP vendors/telcos, this is not a problem of
WebRTC. You should implement SRTP in your legacy and non-secure SIP
devices and make them valid for communication across the open Internet
in which security is a MUST (Internet is not a telco wallen garden).
The main purpose of WebRTC is not to interoperate with insecure
devices, do we all agree here?

I don't support this kind of arguments in favour of non mandating SRTP.

PS: Somebody could argue that, in the Web, neither HTTPS or
WebSocket+TLS is a MUST but optional per website, so why to make SRTP
mandatory? That would be a very different argument I could understand
and discuss about. But forcing a *new* specification to be insecure
just to allow interoperability with non-secure devices is not welcome.
WebRTC is for the Web, not for SIP.

PS: This kind of discussions give the reason to recent comments like
the one from Tim Parton. This WG is too much focused on SIP
vendors/telcos which are not fully interested in RTC communications in
pure Web/Internet environments, but in making the web browsers a new
SIP phone for integratting them into their telco business. Bad.

PS: I'm also interested in interoperability between WebRTC browsers
and SIP devices (as much as you), but I assume that just a few SIP
devices MUST be able to interop with WebRTC (those that have done
their homeworks by implementing SRTP and ICE).

And those discussions are becoming very boring. There are not new
arguments at all. It seems than within next weeks/months, SIP
telcos/vendors will continue requesting not mandatory SRTP just to
facilitate their business without investing in improving their
non-secure devices. This is a no-go.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 9 Nov 2011 12:13:04 +0000

Cb,

Please read inline.

Thanks
Partha

From: Cameron Byrne [mailto:[email-masked]]
Sent: Wednesday, November 09, 2011 8:58 AM
To: Ravindran Parthasarathi
Cc: &lt,[email-masked]&gt,
Subject: RE: [rtcweb] SRTP requirement - wiretapping (Re: Let's define the purpose of WebRTC)

Bob and Alice work for Toobigtofail Inc. They are on the same LAN segment and using webrtc to communicate about making a large investment. On that same LAN segment there is a compromised host intercepting all traffic (it did some arp spoofing or something like that )

<partha> I guess that your argument is not specific to webRTC but includes all real-time communication in Enterprise. My point is that this security concern is not generic enough as mentioned in the other mail thread.  </partha>

Cb
>
>
> From: Cameron Byrne [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: &lt,[email-masked]<mailto:[email-masked]>&gt,

---

From: Neil Stratford <[email-masked]>
Date: Wed, 9 Nov 2011 12:53:15 +0000

Wouldn't it be great if we had an opportunity to start from a clean sheet,
carry no legacy baggage and design a platform for the future? Isn't that
the opportunity presented by WebRTC?

It will always be possible to gateway to legacy SIP devices, even if we
have to bridge the media. It seems there is far too much focus on interop
and not enough on what is best for the WebRTC platform.

Neil

On Wed, Nov 9, 2011 at 11:58 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> > I am thinking we could burn SRTP into the browser such that the decision
> of whether or not to use SRTP vests solely with the browser.
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 9 Nov 2011 14:00:10 +0100

2011/11/9 Neil Stratford <[email-masked]>:
> carry no legacy baggage and design a platform for the future? Isn't that the
> opportunity presented by WebRTC?
> It will always be possible to gateway to legacy SIP devices, even if we have
> to bridge the media. It seems there is far too much focus on interop and not
> enough on what is best for the WebRTC platform.

Hi Neil, IMHO trying to create a "new RTC protocol" is not the best
option. IMHO we can learn and reuse existing technologies and
specifications. Honestly I don't think it would be positive to
reinvent the wheel about RTP and SDP. RTP is the standard media
protocol and it's good enough. And SDP is a protocol/format to control
such RTP communication.

Creating a new like-RTP/SDP would take long years and we would get
nothing much better. The point is that WebRTC must define its own
requirements rather than implementing RTP in the way SIP telcos desire
just to interoperate with their legacy-and-never-secure SIP devices.

IMHO SRTP and ICE is the way to go (I would say the same even if SIP
or XMPP-Jingle don't exist).

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 9 Nov 2011 14:04:55 +0100

If you want to be in the world of telecommunications you carry a legacy baggage.

Your proposal to provide a gateway is just one way of dealing with the legacy baggage. It does however carry the downside that you need a player to provide such gateways in support of interworking to the legacy.

Suppose I make an emergency call to a PSAP. The legacy baggage here is that unless someone volunteers to provide all those PSAPs worldwide with new kit, the majority will remain connected to the PSTN (i.e. not even SIP). I need a guarantee that someone out there will provide a gateway. Which player provides that in your business model.

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Neil Stratford
Sent: 09 November 2011 12:53
To: Iñaki Baz Castillo
Cc: [email-masked]
Subject: Re: [rtcweb] Let's define the purpose of WebRTC

Wouldn't it be great if we had an opportunity to start from a clean sheet, carry no legacy baggage and design a platform for the future? Isn't that the opportunity presented by WebRTC?

It will always be possible to gateway to legacy SIP devices, even if we have to bridge the media. It seems there is far too much focus on interop and not enough on what is best for the WebRTC platform.

Neil

On Wed, Nov 9, 2011 at 11:58 AM, Iñaki Baz Castillo <[email-masked]<mailto:[email-masked]>> wrote:

So no security. Bad.

You mean the user.

Regards.

--
Iñaki Baz Castillo
<[email-masked]<mailto:[email-masked]>>
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 9 Nov 2011 18:49:35 +0530

|That opens up for downgrade attacks and put a lot 
|of trust on the web browser UI to show what happens
|and on the users to understand what the web browser 
|UA is trying to tell them.

It isn't an attack per se (since a malicious JS no control over it), rather a choice we would have to make whether or not to allow insecure calling to non-WebRTC clients. Yes, it adds some burden on the UI, but could be as simple as a red cross you see on https URL when the browser detects either high-risk insecure content on the page or problems with the site's certificate.

Muthu

|-----Original Message-----
|From: Olle E. Johansson [mailto:[email-masked]]
|Sent: Wednesday, November 09, 2011 4:54 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: Iñaki Baz Castillo; Avasarala, Ranjit; Ravindran Parthasarathi; Cullen Jennings (fluffy);
[email-masked]
|Subject: Re: [rtcweb] Let's define the purpose of WebRTC
|
|
|9 nov 2011 kl. 11:57 skrev Muthu Arul Mozhi Perumal (mperumal):
|
|> |The "application" is untrusted by nature, and we don't want
|> |to make the end-user to decide whether to trust it or not.
|> |Explained many times in this maillist.
|>
|> I am thinking we could burn SRTP into the browser such that the decision of whether or not to use
|SRTP vests solely with the browser. If a WebRTC browser is exchanging media with another WebRTC
|browser they always do SRTP/SRTCP. If either side isn't WebRTC compliant they end up with RTP/RTCP.
|This way we don't need to trust the JS, instead trust only the browser. We can also interoperate with
|legacy devices without taxing them.
|
|That opens up for downgrade attacks and put a lot of trust on the web browser UI to show what happens
|and on the users to understand what the web browser UA is trying to tell them.
|
|/O

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 9 Nov 2011 19:06:47 +0530

I was trying to envision a solution for the "untrusted JS" issue and I don't intend to argue on whether or not we should allow insecure calling to non-WebRTC clients.

|The "browser" cannot decide that. Probably you mean the user

Yes, a decision made by the browser with user consent if required, with no application involvement.

|And what you state is that, in case the peer does not annouce 
|support for SRTP then the browser should downgrade security 
|to plain RTP.

No, not based on the SRTP capability advertised by the peer, rather based on whether the peer claims it is WebRTC compliant (to make sure calls b/w WebRTC clients are always secure).

|The user (web visitor) has no way to know whether the WebRTC 
|application will contact a WebRTC browser or another device 
|at the media plane.

We could add a STUN extension to indicate compliance to WebRTC, including the supported version level if we ever come up with WebRTC2.0.

Muthu

|-----Original Message-----
|From: Iñaki Baz Castillo [mailto:[email-masked]]
|Sent: Wednesday, November 09, 2011 5:28 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: Avasarala, Ranjit; Ravindran Parthasarathi; Cullen Jennings (fluffy); Olle E. Johansson;
[email-masked]
|Subject: Re: [rtcweb] Let's define the purpose of WebRTC
|
|2011/11/9 Muthu Arul Mozhi Perumal (mperumal) <[email-masked]>:
|> I am thinking we could burn SRTP into the browser such that the decision of whether or not to use
|SRTP vests solely with the browser.
|
|The "browser" cannot decide that. Probably you mean the user, that
|person that in 99.999% of cases does not know what "encryption" or
|"SRTP" is, and in 85% of cases does not matter about security.
|
|
|> If a WebRTC browser is exchanging media with another WebRTC browser they always do SRTP/SRTCP.
|
|The browser has NO way to determine whether it's exchanging media with
|another browser or not. And what you state is that, in case the peer
|does not annouce support for SRTP then the browser should downgrade
|security to plain RTP. The user (web visitor) has no way to know
|whether the WebRTC application will contact a WebRTC browser or
|another device at the media plane.
|
|
|> If either side isn't WebRTC compliant they end up with RTP/RTCP.
|
|So no security. Bad.
|
|
|> This way we don't need to trust the JS, instead trust only the browser.
|
|You mean the user.
|
|
|> We can also interoperate with legacy devices without taxing them.
|
|Sorry, but WebRTC is about "realtime communications for the Web",
|rather than "SIP business coming to the Web". SIP uses RTP, including
|RFC's about SRTP. If you want SIP interoperability with a WebRTC
|device, then make your work as vendor and add security to your SIP
|devices rather than asking no-security for WebRTC.
|
|Please, take a look to XMPP/Jingle !!  They implement SRTP and ICE
|from the beginning!! *Do* your homeworks as SIP vendor.
|
|This is a problem of SIP vendors/telcos, this is not a problem of
|WebRTC. You should implement SRTP in your legacy and non-secure SIP
|devices and make them valid for communication across the open Internet
|in which security is a MUST (Internet is not a telco wallen garden).
|The main purpose of WebRTC is not to interoperate with insecure
|devices, do we all agree here?
|
|I don't support this kind of arguments in favour of non mandating SRTP.
|
|
|PS: Somebody could argue that, in the Web, neither HTTPS or
|WebSocket+TLS is a MUST but optional per website, so why to make SRTP
|mandatory? That would be a very different argument I could understand
|and discuss about. But forcing a *new* specification to be insecure
|just to allow interoperability with non-secure devices is not welcome.
|WebRTC is for the Web, not for SIP.
|
|PS: This kind of discussions give the reason to recent comments like
|the one from Tim Parton. This WG is too much focused on SIP
|vendors/telcos which are not fully interested in RTC communications in
|pure Web/Internet environments, but in making the web browsers a new
|SIP phone for integratting them into their telco business. Bad.
|
|PS: I'm also interested in interoperability between WebRTC browsers
|and SIP devices (as much as you), but I assume that just a few SIP
|devices MUST be able to interop with WebRTC (those that have done
|their homeworks by implementing SRTP and ICE).
|
|
|And those discussions are becoming very boring. There are not new
|arguments at all. It seems than within next weeks/months, SIP
|telcos/vendors will continue requesting not mandatory SRTP just to
|facilitate their business without investing in improving their
|non-secure devices. This is a no-go.
|
|
|Regards.
|
|
|--
|Iñaki Baz Castillo
|<[email-masked]>

---

From: Neil Stratford <[email-masked]>
Date: Wed, 9 Nov 2011 13:42:48 +0000

>  If you want to be in the world of telecommunications you carry a legacy

Only at the point you want to interop with that legacy world. Skype did a
pretty good job of avoiding the legacy and changing users expectations of
telecommunications.

Your proposal to provide a gateway is just one way of dealing with the
> legacy baggage. It does however carry the downside that you need a player
> to provide such gateways in support of interworking to the legacy.****
>
> ** **
>
> Suppose I make an emergency call to a PSAP. The legacy baggage here is
> that unless someone volunteers to provide all those PSAPs worldwide with
> new kit, the majority will remain connected to the PSTN (i.e. not even
> SIP). I need a guarantee that someone out there will provide a gateway.
> Which player provides that in your business model.
>

If there is a market for interop (which there clearly is) then multiple
vendors will no doubt offer gateways. I'm just concerned that we are
talking about imposing legacy requirements on the core API, when WebRTC
seems an ideal opportunity to break away from that legacy.

Neil

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 9 Nov 2011 14:44:01 +0100

> We could add a STUN extension to indicate compliance to WebRTC, including the supported version level if we ever come up with WebRTC2.0.

And what is the advantage? you still say exactly the same: a WebRTC
client "MUST" allow plain RTP if the peer is not a WebRTC client. Why
is that an argument in favour of non mandating SRTP?

If I'm in a shared WiFi network and receive a call from a non-WebRTC
client not supporting SRTP, my neighbors can intercept it. What does
such "STUN extension" provides here? just nothing.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 9 Nov 2011 13:47:49 +0000

Neil,

Please read inline

Thanks
Partha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Neil Stratford
Sent: Wednesday, November 09, 2011 7:13 PM
To: DRAGE, Keith (Keith)
Cc: [email-masked]
Subject: Re: [rtcweb] Let's define the purpose of WebRTC

On Wed, Nov 9, 2011 at 1:04 PM, DRAGE, Keith (Keith) <[email-masked]<mailto:[email-masked]>> wrote:
If you want to be in the world of telecommunications you carry a legacy baggage.

Only at the point you want to interop with that legacy world. Skype did a pretty good job of avoiding the legacy and changing users expectations of telecommunications.
<partha> AFAIK, Skype still interop with legacy telephone devices using SIP </partha>

If there is a market for interop (which there clearly is) then multiple vendors will no doubt offer gateways. I'm just concerned that we are talking about imposing legacy requirements on the core API, when WebRTC seems an ideal opportunity to break away from that legacy.
<partha>  In case core API is not defined for it, I agree with Keith that RTCWeb has to explain or provide the guideline for the server/gateway role and IMO, it is discussed as federation till now in RTCWeb.  </partha>

Neil

---

From: Tim Panton <[email-masked]>
Date: Wed, 9 Nov 2011 13:54:50 +0000

On 9 Nov 2011, at 13:42, Neil Stratford wrote:

> On Wed, Nov 9, 2011 at 1:04 PM, DRAGE, Keith (Keith) <[email-masked]> wrote:

ViVOX is carrying more wideband minutes than the whole 'telecommunications' world. g722 has been around so long the patents
have expired, but I still don't see the legacy world deploying it.

> If there is a market for interop (which there clearly is) then multiple vendors will no doubt offer gateways. I'm just concerned that we are talking about imposing legacy requirements on the core A…

We need to be _very_ careful about  supporting emergency calls - what is an emergency in Hobbo hotel or the-simuls-on-line isn't necessarily
a case for deployment of real Blue-light vehicles. 

(A classic game play in The Sims is to burn your house down and call the (sims) fire brigade - some cool stuff happens - or so Smallest Daughter
tells me).

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 9 Nov 2011 14:59:40 +0100

Hi Partha, just as a suggestion it would be great if you could make
correct usage of your mail client and configure it to properly
generate mail responses (by adding ">" in front of the text you are
replying) so you could stop adding <partha> to point your own text.
Writing mails in plain text (without HTML and colorized text) is also
desirable as stated in Netiquette and make easier reading your mails
to others.

More inline:

> <partha> AFAIK, Skype still interop with legacy telephone devices using SIP

Yes, but they use their own gateways and don't bothers their end users
by making Skype software to allow non secure communications. The work
is done in their gateways.

In the same way, if you want WebRTC to interoperate at media plane
with your legacy-non-secure-at-all SIP/RTP infrastructure, then build
a gateway or whatever you need. This is not the task of WebRTC nor
this WG.

> vendors will no doubt offer gateways. I'm just concerned that we are talking
> about imposing legacy requirements on the core API, when WebRTC seems an
> ideal opportunity to break away from that legacy.
>
> <partha>  In case core API is not defined for it, I agree with Keith that
> RTCWeb has to explain or provide the guideline for the server/gateway role
> and IMO, it is discussed as federation till now in RTCWeb.  </partha>

You should forget about "federation in WebRTC". That's a no-go. If a
WebRTC scenario wants to interoperate with other WebRTC scenario or
with a SIP/H323/Jingle network, they both should agree on the terms of
the interoperation between their systems. The only WebRTC can state
about that is an "empty" text like "they can use SIP/XMPP or whatever
protocol/mechanism they decide in order to interoperate" which is the
very same as saying "do whatever you want".

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 Nov 2011 06:09:43 -0800

> Enterprise WebRTC application wherein SRTP is not required to be mandated.

Partha,

I don't understand what resource you are conserving here by avoiding
multiple encryption.

Even if we stipulate that the enterprise network is secure (which as
Cameron has suggested, is often not the case even when people believe it is),
the actual cost to encrypt the data on the endpoints is quite low,
especially when compared to the added complexity cost of trying to make the
(extremely difficult) determination of whether whatever network encryption
is in place is sufficient to protect your call. Better to just encrypt all
the time.

-Ekr

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 9 Nov 2011 20:02:16 +0530

|And what is the advantage? you still say exactly the 
|same: a WebRTC client "MUST" allow plain RTP if the 
|peer is not a WebRTC client. Why is that an argument 
|in favour of non mandating SRTP?

We seem to have a group of people concerned about the cost associated with having to upgrade/replace/supplement their non-SRTP capable gears such as PSTN gateways, and I was sympathetic towards them -:) 

|If I'm in a shared WiFi network and receive a call from 
|a non-WebRTC client not supporting SRTP, my neighbors can 
|intercept it.

If the shared WiFi network hasn't employed WiFi encryption, then you would probably be more concerned with your neighbors intercepting all of your traffic than just RTP -:)

|What does such "STUN extension" provides here?

It would tell the browser that the peer (browser) claims WebRTC compliance and so shouldn't allow insecure calling (the STUN extension is added by the browser and the applications has no control over it).

Muthu

|-----Original Message-----
|From: Iñaki Baz Castillo [mailto:[email-masked]]
|Sent: Wednesday, November 09, 2011 7:14 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: Avasarala, Ranjit; Ravindran Parthasarathi; Cullen Jennings (fluffy); Olle E. Johansson;
[email-masked]
|Subject: Re: [rtcweb] Let's define the purpose of WebRTC
|
|2011/11/9 Muthu Arul Mozhi Perumal (mperumal) <[email-masked]>:
|> |And what you state is that, in case the peer does not annouce
|> |support for SRTP then the browser should downgrade security
|> |to plain RTP.
|>
|> No, not based on the SRTP capability advertised by the peer, rather based on whether the peer claims
|it is WebRTC compliant (to make sure calls b/w WebRTC clients are always secure).
|>
|> |The user (web visitor) has no way to know whether the WebRTC
|> |application will contact a WebRTC browser or another device
|> |at the media plane.
|>
|> We could add a STUN extension to indicate compliance to WebRTC, including the supported version
|level if we ever come up with WebRTC2.0.
|
|And what is the advantage? you still say exactly the same: a WebRTC
|client "MUST" allow plain RTP if the peer is not a WebRTC client. Why
|is that an argument in favour of non mandating SRTP?
|
|If I'm in a shared WiFi network and receive a call from a non-WebRTC
|client not supporting SRTP, my neighbors can intercept it. What does
|such "STUN extension" provides here? just nothing.
|
|
|
|
|
|--
|Iñaki Baz Castillo
|<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 9 Nov 2011 09:33:11 -0500

> is that an argument in favour of non mandating SRTP?
What I have not seen on this list is why SRTP must be used for all the
calls. The things I've seen so far:
1. SRTP must be used everywhere since security is good
2. We are innovative so we must use SRTP everywhere
3. We do not trust the user or the application so we must use SRTP
everywhere
4. We must have SRTP in order to have consensus.

I think except the fact that security is generally a good thing, non of
these arguments are relevant.

What I was trying to say that there are number of situations where:

1. SRTP is useless: If we do not trust the application (application is
delivered over HTTP), there is no point to encrypt the media. Application
can send this media to some box in the middle and record it, without user
ever knowing. Requiring SRTP in this case is almost like trying to lock the
window when your door is open.

2. SRTP is not required: If we are dealing with a greeting card application
or game chat, no one expects security. If security can be provided this
will probably not hurt anybody, but in the end it will serve no purpose
there.

3. SRTP is undesirable: As I've mentioned before there are places and
situations where encryption is either makes things more difficult (like
interop with legacy devices, debugging, or building new software). In these
cases, having SRTP as a must just introduces a higher barrier to entry the
needs to be overcome in order to communicate with WebRTC. This is not
something critical, but it will make things more difficult and will work
against innovation.

4. SRTP is illegal: I am not talking about wiretapping. I do not propose to
create any types of back doors in WebRTC in order to intercept the
communications. All I am saying that application developer should have an
option not to encrypt its traffic to comply with local laws or regulations.
I do not think there is a single user faced communication protocol that
does not provide a non secure alternative (HTTP vs HTTPS, SMTP and IMAP
over TCP vs TLS, etc). I do not see why WebRTC must be the first protocol
not to have an unencrypted option.

What I would propose is to allow RTP communications from sessions initiated
by HTTP and require SRTP (or a user consent) for sessions started from
HTTPS. This should be similar to current HTTPS vs HTTP model for
javascript, and will require security where it will do some good vs places
where it is going to be useless.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 9 Nov 2011 16:05:12 +0100

> We seem to have a group of people concerned about the cost associated with having to upgrade/replace/supplement their non-SRTP capable gears such as PSTN gateways, and I was sympathetic towards the…

That's *your* problem. But you want to translate *your* problem into
WebRTC users by making their communications non secure.

Implementing SRTP is really easier and cheap. There is no reason at
all not to mandate it in a new specification, even less when it's
designed to work in the open (and untrusted) Internet.

So bad luck. You, telcos, have the specs and the tools to upgrade your
non-secure SIP devices. Do it.

> If the shared WiFi network hasn't employed WiFi encryption, then you would probably be more concerned with your neighbors intercepting all of your traffic than just RTP -:)

It was just an example. Think about so many open WiFi networks in
airports (captive portals with no encryption).

> It would tell the browser that the peer (browser) claims WebRTC compliance and so shouldn't allow insecure calling (the STUN extension is added by the browser and the applications has no control ov…

I insist: that provides nothing. It just means that me, a WebRTC user,
could have a non-secure media session in case the remote peer is not a
WebRTC peer (or a peer implementing SRTP). It solves nothing. It makes
my communication unsafe regardless I'm a WebRTC client implementing
SRTP. *My* security should NOT depend on the security implemented in
the peer (since I cannot trust the peer, never).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Randell Jesup <[email-masked]>
Date: Wed, 09 Nov 2011 12:29:58 -0500

> It isn't an attack per se (since a malicious JS no control over it), rather a choice we would have to make whether or not to allow insecure calling to non-WebRTC clients. Yes, it adds some burden o…

It's a network/server-based attack, or it's an attack perpetrated by the 
JS app by sending the call to an unencrypted MiTM tapping point instead 
of directly to the intended recipient.

ekr and Mozilla (and probably some others) have been working on/thinking 
about how we can minimize the risk of MiTM attacks, and provide the user 
with some idea of whom they're talking to (Evil Hacker or My Buddy Jim).

-- 
Randell Jesup
[email-masked]

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 10 Nov 2011 00:01:46 +0530

|That's *your* problem. But you want to translate 
|*your* problem into WebRTC users by making their 
|communications non secure.

Well, most often you as a WebRTC user will be the one who would want to reach someone behind legacy systems or as someone offering WebRTC service would want your users be able to reach other users behind such systems. Large organizations would probably build their own media gateways, while smaller ones would probably get taxed by providers for offering such media gateway service. 

|Implementing SRTP is really easier and cheap.

Sure, in a browser. But, may not be for a provider.

|You, telcos, have the specs and the tools to upgrade your
|non-secure SIP devices. Do it.

If you are willing to pay for it, I don't see why the tolcos won't -:)

|*My* security should NOT depend on the security 
|implemented in the peer (since I cannot trust the 
|peer, never).

Good luck. You peer could be a media gateway sitting somewhere in the Internet converting SRTP to RTP and sending to the other part of the world.

Muthu

|-----Original Message-----
|From: Iñaki Baz Castillo [mailto:[email-masked]]
|Sent: Wednesday, November 09, 2011 8:35 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: Avasarala, Ranjit; Ravindran Parthasarathi; Cullen Jennings (fluffy); Olle E. Johansson;
[email-masked]
|Subject: Re: [rtcweb] Let's define the purpose of WebRTC
|
|2011/11/9 Muthu Arul Mozhi Perumal (mperumal) <[email-masked]>:
|> |And what is the advantage? you still say exactly the
|> |same: a WebRTC client "MUST" allow plain RTP if the
|> |peer is not a WebRTC client. Why is that an argument
|> |in favour of non mandating SRTP?
|>
|> We seem to have a group of people concerned about the cost associated with having to
|upgrade/replace/supplement their non-SRTP capable gears such as PSTN gateways, and I was sympathetic
|towards them -:)
|
|That's *your* problem. But you want to translate *your* problem into
|WebRTC users by making their communications non secure.
|
|Implementing SRTP is really easier and cheap. There is no reason at
|all not to mandate it in a new specification, even less when it's
|designed to work in the open (and untrusted) Internet.
|
|So bad luck. You, telcos, have the specs and the tools to upgrade your
|non-secure SIP devices. Do it.
|
|
|
|> |If I'm in a shared WiFi network and receive a call from
|> |a non-WebRTC client not supporting SRTP, my neighbors can
|> |intercept it.
|>
|> If the shared WiFi network hasn't employed WiFi encryption, then you would probably be more
|concerned with your neighbors intercepting all of your traffic than just RTP -:)
|
|It was just an example. Think about so many open WiFi networks in
|airports (captive portals with no encryption).
|
|
|
|> |What does such "STUN extension" provides here?
|>
|> It would tell the browser that the peer (browser) claims WebRTC compliance and so shouldn't allow
|insecure calling (the STUN extension is added by the browser and the applications has no control over
|it).
|
|I insist: that provides nothing. It just means that me, a WebRTC user,
|could have a non-secure media session in case the remote peer is not a
|WebRTC peer (or a peer implementing SRTP). It solves nothing. It makes
|my communication unsafe regardless I'm a WebRTC client implementing
|SRTP. *My* security should NOT depend on the security implemented in
|the peer (since I cannot trust the peer, never).
|
|
|
|--
|Iñaki Baz Castillo
|<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 9 Nov 2011 20:33:56 +0100

2011/11/9 Muthu Arul Mozhi Perumal (mperumal) <[email-masked]>:
> Well, most often you as a WebRTC user will be the one who would want to reach someone behind legacy systems

You could consider that people in internet is not so excited with the
possibility of making a legacy PSTN from the browser. In fact, calling
a PSTN number from a web has no added value at all. Users already have
their legacy PSTN phones.

> Sure, in a browser. But, may not be for a provider.

Sure they can scale their systems.

> If you are willing to pay for it, I don't see why the tolcos won't -:)

I should not pay a telco for making my call safe. The telco should do it.

> Good luck. You peer could be a media gateway sitting somewhere in the Internet converting SRTP to RTP and sending to the other part of the world.

Of course, but at least, I will know that the call is secure within my
local network. Imagine I open my laptop in an airport, connect to a
open WiFi (cautive portal) and make a call to another user via web,
but the server must route it (via a SIP gateway) to a SIP softswitch,
and that makes my call to use plain RTP. I'm in an airport, in an open
WiFi network. Bad.

But if my call uses SRTP until the SIP media gateway, then it could
use plain RTP in the PSTN network. That's not so dangerous.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 9 Nov 2011 20:54:50 +0100

Hi,

> their legacy PSTN phones.

I don't think we shall speculate in how people will use, and to whom the will call, using their browser apps.

AFAIK, most SIP calls today end up in PSTN, and the browser technology will allow people to access "SIP phones" from more or less any computer connected to the internet.

> use plain RTP in the PSTN network. That's not so dangerous.

So, in your example you are basically talking about "access network security", because you don't really care what happens (with regards to media security) after the WiFi access leg?

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 9 Nov 2011 21:18:50 +0100

> So, in your example you are basically talking about "access network security", because you don't really care what happens (with regards to media security) after the WiFi access leg?

No. I said that, in case the other end is a PSTN peer, most *probably*
the call would end in a PSTN gateway which routes the call via PSTN,
so more or less "trusted".

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 10 Nov 2011 05:19:23 +0000

Eric,

I agree with you about performance in case of desktop as I'm able to execute Skype video call and other application simultaneously without any performance impact. AFAIK in case of telepresence or equivalent endpoint, it requires the special hardware to encrypt/decrypt the whole bunch of media from it. WebRTC browser could be executed on any of these kind of endpoint as well.

As you mentioned, I often heard that Enterprise is not secure which requires different level of security but this argument is not well accepted in the deployment so far :-( 

Thanks
Partha

>From: Eric Rescorla [mailto:[email-masked]]
>Sent: Wednesday, November 09, 2011 7:40 PM
>To: Ravindran, Parthasarathi
>Cc: Cameron Byrne; &lt,[email-masked]&gt,

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 Nov 2011 21:20:48 -0800

On Wed, Nov 9, 2011 at 6:33 AM, Roman Shpount <[email-masked]> wrote:
> On Wed, Nov 9, 2011 at 8:44 AM, Iñaki Baz Castillo <[email-masked]> wrote

> or game chat, no one expects security. If security can be provided this will
> probably not hurt anybody, but in the end it will serve no purpose there.

I'm focusing solely on this point because I think it does such a good job
of demonstrating the limitations of this kind of "who would ever want security
for application X" thinking.

I can envision situations on which security would be desirable in both of
these applications. In the case of a "greeting card application" (whatever
that is) my greeting card might contain sensitive personal or medical
information (congratulations on your pregnancy, sorry to hear you have
cancer etc.) Surely I do in fact want that information secured. Similarly,
it might not be important to have my Farmville chats secure, but if the
purpose of an in-game chat is for me and my co-player to cooperate
in a game where money is on the line (e.g., a tournament), then suddenlu
security becomesmuch more important. Not to mention that the players
may simply be using in-game chat to discuss personal stuff.

The point is that it's very hard to anticipate which communications media
will be used for sensitive information. To say "we don't need security
in this application because nobody will ever use it to discuss sensitive
stuff" is short-sighted. Better simply to be secure all the time.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 Nov 2011 21:24:04 -0800

> I agree with you about performance in case of desktop as I'm able to execute Skype video call and other application simultaneously without any performance impact. AFAIK in case of telepresence or e…

I'd be interested in any measurements you have to offer here.
My Macbook Air does on the order of 100 MB/s of AES-128
on a single core. What's the bandwidth of a telepresence
system?

-Ekr

---

From: Roman Shpount <[email-masked]>
Date: Thu, 10 Nov 2011 00:48:48 -0500

> stuff" is short-sighted. Better simply to be secure all the time.
So why is 99% of the web traffic is HTTP? Do you want to force everybody to
use HTTPS? I think your argument is simply stating encryption is good, no
encryption bad, even if it is not needed or if it does not protect anything
(WebRTC application delivered over HTTP).
_____________
Roman Shpount

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 10 Nov 2011 05:40:55 +0000

Eric,

Of course, the bandwidth requirement is range from 4MB/s to 16MB/s based on deployment but the point to be noted is that the device is not doing encryption/decryption alone.

Thanks
Partha

>Sent: Thursday, November 10, 2011 10:54 AM
>> I agree with you about performance in case of desktop as I'm able to
>execute Skype video call and other application simultaneously without
>any performance impact. AFAIK in case of telepresence or equivalent
>endpoint, it requires the special hardware to encrypt/decrypt the whole
>bunch of media from it. WebRTC browser could be executed on any of these
>kind of endpoint as well.
>
>> As you mentioned, I often heard that Enterprise is not secure which
>requires different level of security but this argument is not well
>accepted in the deployment so far :-(
>>
>> Thanks
>> Partha
>>
>>>Cameron has suggested, is often not the case even when people believe
>it
>>>is),
>>>especially when compared to the added complexity cost of trying to
>make
>>>the

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 Nov 2011 21:53:46 -0800

> Of course, the bandwidth requirement is range from 4MB/s to 16MB/s based on deployment but the point to be noted is that the device is not doing encryption/decryption alone.

Of course not, but based on the data I just provided and these
bandwidth estimates,
encryption would consume on the order of 5-10% of a relatively modest machine.
Again, do you have any actual measurements that show that crypto is a serious
performance problem?

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 Nov 2011 21:57:26 -0800

> (WebRTC application delivered over HTTP).

My argument is that it's extremely hard to determine a priori
when encryption is needed and when it is not, as evidenced by
the fact that even in the examples *you* suggested, there are
settings when encryption is needed.

As for the question of whether encryption should be used when WebRTC
applications are used over HTTP, as Matthew Kaufman, Alan Johnston,
and myself have all observed, there are technical mechanisms
(albeit suboptimal ones) which can provide security even if the application
is delivered over HTTP (though of course this is still not advisable
for other reasons.)

-Ekr

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 10 Nov 2011 13:09:40 +0530

|At the moment, draft-ietf-rtcweb-rtp-usage does not contain any
|requirement on SRTP usage (the security section says "A mandatory 
|to implement media security solution will be required to be picked", 
|which I think is a bit weak), and the discussion at the time did not 
|seem to indicate consensus that SRTP must be used always, so I 
|decided to document what we seemed to have consensus on - that SRTP 
|MUST be implemented.

Does it mean:
a. The WebRTC browser MUST implement SRTP, but the WebRTC service/JS needn't use it OR
b. The WebRTC browser and the service/JS MUST implement SRTP, but the user needn't have to use it?

thanks,
Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On Behalf Of Harald Alvestrand
|Sent: Monday, November 07, 2011 2:37 PM
|To: José Luis Millán
|Cc: <[email-masked]>
|Subject: [rtcweb] SRTP - mandatory to implement vs mandatory to use (Re: Let's define the purpose of
|WebRTC)
|
|On 11/06/2011 10:16 AM, José Luis Millán wrote:
|> draft-ietf-rtcweb-overview-02 downgraded the SRTP concerns from
|> mandatory-to-use to mandatory-to-implement. So if it does not
|> downgrade anymore, a WebRTC implementation (game app, greeting cards
|> website..) will have to implement SRTP.
|>
|> IMHO, if a web service doesn't want to take, or cannot take, the hit
|> for SRTP, WebRTC is not the appropriate solution for such a service.
|>
|Forking this thread, since it's actually about a line in the documents....
|
|in draft-ietf-rtcweb-overview-02, I changed this section:
|
|5.  Data framing and securing
|
|    SRTP [RFC3550] is used for transport of all real-time media.
|
|    The detailed considerations for usage of functions from RTP and SRTP,
|    as well as for non-media real-time data, are given in <WORKING GROUP
|    DRAFT "MEDIA TRANSPORTS">.
|
|into this section:
|
|5.  Data framing and securing
|
|    The format for media transport is RTP [RFC3550].  Implementation of
|    SRTP [RFC3711] is required for all implementations.
|
|    The detailed considerations for usage of functions from RTP and SRTP
|    are given in [I-D.ietf-rtcweb-rtp-usage].  Key negotiation for SRTP
|    is described in <MISSING>.  Transfer of data that is not in RTP
|    format is described in <MISSING>.
|
|At the moment, draft-ietf-rtcweb-rtp-usage does not contain any
|requirement on SRTP usage (the security section says "A mandatory to
|implement media security solution will be required to be picked", which
|I think is a bit weak), and the discussion at the time did not seem to
|indicate consensus that SRTP must be used always, so I decided to
|document what we seemed to have consensus on - that SRTP MUST be
|implemented.
|
|If we have consensus to make it stronger again, I'm happy to change it back.
|
|                   Harald
|
|
|
|_______________________________________________
|rtcweb mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Randell Jesup <[email-masked]>
Date: Thu, 10 Nov 2011 03:02:12 -0500

> on a single core. What's the bandwidth of a telepresence

I don't have a good benchmark source, but stuff I'm seeing rooting 
around implies that tablet/phone cores like Tegras with AES accelerators 
can run AES-128 at somewhere in the <16MB/s rate, rather lower (1/2?  
1/4? 1/10?) on the CPU (which is likely what we'd be using).    These 
are horribly rough numbers, and might even be optimistic.

If we're down in low single-digit MB/s AES in SW, we might be using a 
noticeable amount of CPU (5, 10%, more) on a tablet or phone in some use 
cases (where we might be pushing around a few 1Mbps streams).

I should note that I don't feel that's likely to influence my opinion; I 
don't think performance on the browser/phone is a significant reason to 
make it optional.  Performance on a low-end webrtc "PBX" box or media 
gateway or mixing server handling a lot of these streams - maybe.  I'm 
not including dedicated custom SBC-like solutions; I'm assuming generic 
HW or cloud services used by a website/service.  But making SRTP 
optional-to-use is fraught with dangers of bid-down attacks; we would 
need to be sure that reducing costs for some services (and thus users) 
doesn't endanger other users.

-- 
Randell Jesup
[email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 10 Nov 2011 09:34:26 +0100

> b. The WebRTC browser and the service/JS MUST implement SRTP, but the user needn't have to use it?
For this group: a, I think.

I haven't seen it realistic to impose restrictions in RTCWEB on the 
Javascript that people write.
The language and the APIs are subjects of standardization; the code 
written isn't.

If someone claims to implement a protocol in Javascript, of course the 
restrictions apply - if they implement a protocol in Javascript where 
crypto is mandatory to implement, and don't implement crypto, their 
claim to have implemented the protocol is false advertising.

But the IETF has no protocol police.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 10 Nov 2011 19:47:19 +0000

> non-secure SIP devices. Do it.

Several people have made this SRTP discussion into a "Telco" issue, and I don't think it is.  First, because if a Telco doesn't care about securing the media, they'll likely put the burden of making it plaintext RTP on the WebRTC domain owner, so it still won't be "their problem".  But more importantly, because I expect a lot of Telco's to actually *require* WebRTC media communications to/from them be secure in some fashion or other, specifically because it can be run to/from anywhere on the public Internet. [they won't do SRTP all the way to their own SIP endpoints, but that doesn't matter]  

So for Telco's I don't think mandating SRTP be used is a non-starter, though the form of key exchange might be a big sticking point.

But something to consider is if doing SRTP is a burden or not on web applications that know a priori that they don't need it.  In particular I mean ones that need to use media servers so it's not simply browser-to-browser, and they use HTTP because their use-case isn't one of a sensitive nature.  

-hadriel
p.s. BTW, I didn't mean to start a religious war on this topic - I was just pointing out that a requirement to use ICE and a requirement to use SRTP aren't tied together, and that we need to still get consensus on mandating SRTP to-use vs. only to-implement.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 10 Nov 2011 21:07:53 +0100

> But something to consider is if doing SRTP is a burden or not on web applications that know a priori that they don't need it.  In particular I mean ones that need to use media servers so it's not s…

I think Eric has killed that kind of use-cases. You simply don't know if the use case isn't of a sensitive nature. Ever.

/O

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 10 Nov 2011 21:30:45 +0100

On 11/10/2011 06:48 AM, Roman Shpount wrote:
>
> On Thu, Nov 10, 2011 at 12:20 AM, Eric Rescorla <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> So why is 99% of the web traffic is HTTP? Do you want to force 
> everybody to use HTTPS? I think your argument is simply stating 
> encryption is good, no encryption bad, even if it is not needed or if 
> it does not protect anything (WebRTC application delivered over HTTP).

Since you asked....

Working, but not speaking, for the company that just decided that open 
Web search results should go over HTTPS: yes.

http://googleblog.blogspot.com/2011/10/making-search-more-secure.html

Having the default Web scheme be nonencrypted and nonsecured was a 
reasonable choice given the cost (and regulatory hassle) of crypto at 
that time. Long term, it was a mistake.

(BTW, Google searches did not immediately bring up verification for that 
claim of 99% of Web traffic being HTTP.... do you have a citation for that?)

                  Harald

---

From: Roman Shpount <[email-masked]>
Date: Thu, 10 Nov 2011 15:51:37 -0500

> claim of 99% of Web traffic being HTTP.... do you have a citation for that?)

Not really, this is just an estimate. Some fact point for you -- facebook
is HTTP and that is about 25% of web page visits. Youtube is HTTP also and
that's about 7%. (
http://weblogs.hitwise.com/heather-dougherty/2010/11/facebookcom_generates_nearly_1_1.html
)

I think the whole discussion degraded to the point of being pointless. You
say that you need mandatory encryption regardless of what I am saying. I
would not agree to mandatory encryption unless you explain to me why this
is not something that WebRTC application developer should not control.
Application developer can circumvent media security in any way he wants (by
sending it to a middle box and recording for example), so I really do not
understand why he cannot just turn the encryption off. On the web, where
origin of applications can be unknown, their integrity uncertain, delivery
un-secure, and purpose unpredictable, I do not understand why you insist on
mandatory encryption. It will not provide more security, will just restrict
things for no real gain.
_____________
Roman Shpount

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 10 Nov 2011 21:07:13 +0000

> may simply be using in-game chat to discuss personal stuff.

I think that's a red herring.  Just because you as a user could post your social security number on a forum website, for example, does not mean all forum websites should use HTTPS "just in case".  Because even if they used HTTPS it's not going to secure your social security number from being read by anyone else, nor does the forum website claim to provide any such form of confidentiality to begin with. 

The greeting card case, for example, is going to record your media on some server somewhere - just because they use SRTP from you to do so doesn't mean they're going to prevent everyone on the planet from being able to access the greeting card; or even if they only allow authorized users to listen to the greeting card, it doesn't mean that they won't simply use an HTTP'ed wav file to deliver it to them.  Obviously if a greeting card app *wants* to provide that sort of confidentiality/privacy, then it can and should use SRTP as well as encrypt everything else, control authorization, etc.  That's their choice, based on what type of application they want to provide.  We don't need to create a nanny state.

> stuff" is short-sighted. Better simply to be secure all the time.

And one could argue this the exact opposite - if the browser shows some lock-icon thing for SRTP, then it's better for them to use RTP instead for such apps, so as not to make you think the service as a whole is secure if it really isn't. The only one who knows the type of application service security model being offered is the Web server admin/developer, not the IETF. 

-hadriel

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 10 Nov 2011 13:34:57 -0800

> I think that's a red herring.  Just because you as a user could post your social security number on a forum website, for example, does not mean all forum websites should use HTTPS "just in case".…

This isn't my point: Roman offered a set of use cases he claimed didn't
require confidentiality. But in fact, many such cases do. The fact that
there are also overlapping cases which do not is an argument for erring
on the side of confidentiality, not the other way around.

> The greeting card case, for example, is going to record your media on some server somewhere - just because they use SRTP from you to do so doesn't mean they're going to prevent everyone on the planet from being able to access the greeting card; or even if they only allow authorized users to listen to the greeting card, it doesn't mean that they won't simply use an HTTP'ed wav file to deliver it to them.  Obviously if a greeting card app *wants* to provide that sort of confidentiality/privacy, then it can and should use SRTP as well as encrypt everything else, control authorization, etc.  That's their choice, based on what type of application they want to provide.

Would that this were in fact true. But I don't think history supports
this argument.
Quite the contrary: we have a whole array of protocols which really should
be secure all the time (e-mail is a good example) but aren't because they
were initially deployed insecure and it's hard to convert. The good
news, however,
is that WebRTC can be done securely from the beginning in a way that
(unlike HTTPS) doesn't impose significant inconvenience on the site operator.

> And one could argue this the exact opposite - if the browser shows some lock-icon thing for SRTP, then it's better for them to use RTP instead for such apps, so as not to make you think the service as a whole is secure if it really isn't.

Obviously, UI confusion is a real problem, but I don't really buy the
argument that
Facebook shouldn't use HTTPS because people will be confused about what
happens when they post on their wall.

-Ekr

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 10 Nov 2011 22:37:05 +0100

On 11/10/2011 09:51 PM, Roman Shpount wrote:
>
> On Thu, Nov 10, 2011 at 3:30 PM, Harald Alvestrand 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     (BTW, Google searches did not immediately bring up verification
>     for that claim of 99% of Web traffic being HTTP.... do you have a
>     citation for that?)
>
>
> Not really, this is just an estimate. Some fact point for you -- 
> facebook is HTTP and that is about 25% of web page visits.
Facts are slippery things. Facebook offers an option to have HTTPS 
always, so every hit from my account on Facebook is HTTPS, not HTTP.
> Youtube is HTTP also and that's about 7%. 
> (http://weblogs.hitwise.com/heather-dougherty/2010/11/facebookcom_generates_nearly_1_1.html)
> I think the whole discussion degraded to the point of being pointless. 
> You say that you need mandatory encryption regardless of what I am saying.
Not really what I was saying.

Since you dragged in the division of traffic between HTTP and HTTPS as 
an argument, I thought I'd state an absolutist position too. That's 
different from what I am looking for when seeking consensus. For some 
reasons why I hold that position, I recommend "Little Brother" by Cory 
Doctorow. It's a fun read.
> I would not agree to mandatory encryption unless you explain to me why 
> this is not something that WebRTC application developer should not 
> control.
I am still waiting for a compelling argument for why the application 
developer *needs* to be able to run without encryption.
So far, we've heard arguments that:

- encryption uses more CPU (true, but arguably not significant compared 
to media processing)
- It is needed for legacy interoperability (may be true for some, but 
not necessarily compelling)
- It helps debugging (which has been disputed by people who debug systems)

Did I miss some?

The ability to turn off encryption increases the opportunity for attacks 
on services that *want* to be secure (bid-down attacks); I think that's 
uncontroversial.

> Application developer can circumvent media security in any way he 
> wants (by sending it to a middle box and recording for example), so I 
> really do not understand why he cannot just turn the encryption off. 
> On the web, where origin of applications can be unknown, their 
> integrity uncertain, delivery un-secure, and purpose unpredictable, I 
> do not understand why you insist on mandatory encryption. It will not 
> provide more security, will just restrict things for no real gain.
And I pursue the argument from the other end: Given that encryption is 
available, and the cost mostly negligible, what is the value of turning 
it *off*?

All that said .... I'm able to live with having the RTCWEB standard 
suite say "mandatory to implement, not mandatory to use". I just think 
the arguments for doing so are weak.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 10 Nov 2011 17:07:36 -0500

On Thu, Nov 10, 2011 at 4:37 PM, Harald Alvestrand <[email-masked]>wrote:

> - encryption uses more CPU (true, but arguably not significant compared to
> media processing)
> - It is needed for legacy interoperability (may be true for some, but not
> necessarily compelling)
Encryption being illegal in some situations is yet another reason (I know
about the IETF position on wiretapping, but I would still argue that this
is a valid reason.)

Higher barrier to entry for building new services -- for instance if you
are building a media server to work with WebRTC client. Having one more
thing to implement before something works is not critical, but makes a
difference.

Debugging is actually not a decided issues since we have not reached
consensus on the key exchange protocol. Depending on it, debugging can be a
lot more or much less difficult. We do provide an SIPS/SRTP/HTTPS enabled
systems and services to our customers, but we are regularly being asked to
turn security off for debugging.

These arguments are not very strong and would not prevent WebRTC from being
used (except the illegal part). My main problem is that mandatory
encryption is not serving any useful purpose. I strongly oppose the
illusion of security when communications are not secure. If an application
is delivered over HTTP, the fact that media is encrypted is irrelevant and
provides no useful security. There is a duality about web based
applications with HTTP and HTTPS. I think WebRTC should reflect this. There
is a working model present for HTTP applications already (secure document
-- secure communications, insecure document -- insecure communications), so
I do not see the reason to break it.
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 10 Nov 2011 14:18:24 -0800

On Thu, Nov 10, 2011 at 2:07 PM, Roman Shpount <[email-masked]> wrote:
>
>
> On Thu, Nov 10, 2011 at 4:37 PM, Harald Alvestrand <[email-masked]>
> used (except the illegal part). My main problem is that mandatory encryption
> is not serving any useful purpose.

But it is serving a useful purpose. It's setting a default floor on
how the systems
behave, as well as reducing implementation complexity and concerns about
bid-down attacks.

>I strongly oppose the illusion of
> security when communications are not secure.

I'd be happy to recommend a less secure-looking UI when the JS was served
over HTTP. Did you have some other concern?

> If an application is delivered
> over HTTP, the fact that media is encrypted is irrelevant and provides no
> useful security.

As I've observed before, this isn't in fact correct. Yes, our currently
existing mechanisms for providing secure communications with
completely insecure signaling are less than optimal, but they do
exist, and as my document makes clear, there are potential approaches
that could make this significantly easier.

> There is a duality about web based applications with HTTP
> and HTTPS. I think WebRTC should reflect this. There is a working model
> present for HTTP applications already (secure document -- secure
> communications, insecure document -- insecure communications), so I do not
> see the reason to break it.

Characterizing this model as "working" seems at best an exaggeration,
as anyone who has had to deal with mixed content, SOP conflicts,
or "secure" cookies can attest.

-Ekr

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 11 Nov 2011 01:15:54 +0000

> on the side of confidentiality, not the other way around.

But the argument isn't about a generic "game-app" or generic "greeting card" WebRTC use-case - it's about a specific "game-app" or "greeting card" application instance.  In other words, of course for a "game-app" use-case we can imagine games which involve money that need media security; but there are "Farmville" and Scrabble and so on games as well, and those are the specific applications that're being proposed don't need it and may not want it.  Likewise, of course there could be greeting-card application sites that purport to provide strong privacy, but there are free ones that do not claim that today.

The subtle difference, I think, is that you're viewing it like WebRTC is a generic application that can be used by different hosting sites for different purposes, whereas I view WebRTC as a toolkit to build different applications - like a library included with my OS or compiler.  So saying "well since someone could use WebRTC for something sensitive we have to assume the worst case" sounds rather odd to me - it's like a compiler removing a library because some programs made for sensitive data could be accidentally using it.  No?

-hadriel
p.s. it's hard to convey emotion/emphasis/conviction in email, so I'd like to mention I'd also be ok with SRTP being mandatory-to-use.  I just think the arguments used so far for doing so have been weak. ;)  
Personally I think a better argument for making it mandatory-to-use is public/press perception. (and no I'm not joking)

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 10 Nov 2011 17:30:08 -0800

On Thu, Nov 10, 2011 at 5:15 PM, Hadriel Kaplan <[email-masked]> wrote:
> But the argument isn't about a generic "game-app" or generic "greeting card" WebRTC use-case - it's about a specific "game-app" or "greeting card" application instance.  In other words, of course for a "game-app" use-case we can imagine games which involve money that need media security; but there are "Farmville" and Scrabble and so on games as well, and those are the specific applications that're being proposed don't need it and may not want it.

I get that that's the argument you're offering, but my point is that people's
intuitions about what's needed are generally wrong. To take the specific
examples you've chosen, why do you think Scrabble doesn't require
security? If people are playing a scrabble tournament, then certainly
there is something riding on the outcome and so security is appropriate.
(This is, for instance, an issue for first person shooters, where tournaments
can have high stakes).

> The subtle difference, I think, is that you're viewing it like WebRTC is a generic application that can be used by different hosting sites for different purposes, whereas I view WebRTC as a toolkit…

I would say a better analogy is a system declining to offer APIS which are known
to be extremely dangerous (since we are building a new system it's not really
a question of removing.) And indeed this is good practice. Imagine all the
security vulnerabilities which could have been avoided if the C standard library
had not included strcpy().

-Ekr

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Fri, 11 Nov 2011 05:20:44 +0000

Eric,

10% performance impact due to (security) service is a impact on the system. In case of walled garden (Enterprise) network, there is no need to design the system which always requires of 10% performance w.r.t general purpose hardware and obvious choice is to come up with custom build hardware which reduces the cost of system and solution. But your proposal of "mandatory to implement" forces these kind of solution to increase the cost unnecessarily. So, I argue for "mandatory to implement" in browser but against "mandatory to use" which breaks these kind of deployment model.

Thanks
Partha

>Sent: Thursday, November 10, 2011 11:24 AM
>> Of course, the bandwidth requirement is range from 4MB/s to 16MB/s
>based on deployment but the point to be noted is that the device is not
>doing encryption/decryption alone.
>

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 11 Nov 2011 08:14:10 +0100

On 11/10/2011 11:07 PM, Roman Shpount wrote:
>
> These arguments are not very strong and would not prevent WebRTC from 
> being used (except the illegal part). My main problem is that 
> mandatory encryption is not serving any useful purpose. I strongly 
> oppose the illusion of security when communications are not secure. If 
> an application is delivered over HTTP, the fact that media is 
> encrypted is irrelevant and provides no useful security. There is a 
> duality about web based applications with HTTP and HTTPS. I think 
> WebRTC should reflect this. 
I still don't get this. The same logic would say that there's no reason 
to use WPA for your home wireless network as long as you're only sending 
HTTP. Firesheep to the rescue.

Encryption of the media path protects you against *some* of the 
attackers *some* of the time.
Only a solidly designed end-to-end-protected mechanism, including safe 
storage of keying materials in locations where zero-day exploits can't 
get at them, will protect you against *all* the attackers *all* of the 
time (as long as the attackers didn't make your hardware, OS or 
application).

> There is a working model present for HTTP applications already (secure 
> document -- secure communications, insecure document -- insecure 
> communications), so I do not see the reason to break it.
I don't see that one working, either. Witness the number of HTTP sites 
that use HTTPS form submission (the document's vulnerable to attacker, 
yet sent over a trusted path), or the number of times my Chrome warns me 
about mixed content from well-renowned sites.

The current ecosystem is an out-and-out muddle, not a clean model. And 
the exploits are rife.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 11 Nov 2011 09:49:39 +0100

10 nov 2011 kl. 23:07 skrev Roman Shpount:

> 
> 
> On Thu, Nov 10, 2011 at 4:37 PM, Harald Alvestrand <[email-masked]> wrote:
> - encryption uses more CPU (true, but arguably not significant compared to media processing)
> - It is needed for legacy interoperability (may be true for some, but not necessarily compelling)
> Encryption being illegal in some situations is yet another reason (I know about the IETF position on wiretapping, but I would still argue that this is a valid reason.)
> 
> Higher barrier to entry for building new services -- for instance if you are building a media server to work with WebRTC client. Having one more thing to implement before something works is not critical, but makes a difference.

If you support DTMF in RTP you already have a requirement that you SHOULD  only do that over SRTP. If rtcweb supports telephony-events, we are already on the SRTP side as almost mandatory. I think it's easier to reach an agreement on SRTP being mandatory than DTMF being dis-allowed.

Appendix A of RFC 4733:
"The Security Considerations section is updated to mention the
   requirement for protection of integrity.  More importantly, it makes
   implementation of SRTP [7] mandatory for compliant implementations,
   without specifying a mandatory-to-implement method of key
   distribution."

"The telephone-event payload defined in this specification is highly
   compressed.  A change in value of just one bit can result in a major
   change in meaning as decoded at the receiver.  Thus, message
   integrity MUST be provided for the telephone-event payload type.

   To meet the need for protection both of confidentiality and
   integrity, compliant implementations SHOULD implement the Secure
   Real-time Transport Protocol (SRTP) [7]."

Section 6 of RFC 4733 - an RFC that makes 2833 obsolete.

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 11 Nov 2011 10:01:22 +0100

> But the argument isn't about a generic "game-app" or generic "greeting card" WebRTC use-case - it's about a specific "game-app" or "greeting card" application instance.  In other words, of course f…

Let's use scrabbel as an example. In Sweden, there's a very popular app for iPhone and Android called WordFeud, which is scrabble. It recently added chat. Now, that chat is not protected at all. The application moved from being "harmless" in your view, to being "potentially in need of confidentiality". 

If we avoid having to classify applications and access networks and just provide the security, applications may glide. They may add audio and video and chat without risking stuff.

/O

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 11 Nov 2011 10:11:11 +0100

> The subtle difference, I think, is that you're viewing it like WebRTC is a generic application that can be used by different hosting sites for different purposes, whereas I view WebRTC as a toolkit…
I'd prefer the analogy of Java deciding to not support raw pointers.
Sure, it reduces the expressive power of the language compared to C++, 
but it has certain benefits.

---

From: Roman Shpount <[email-masked]>
Date: Fri, 11 Nov 2011 07:02:31 -0500

On Fri, Nov 11, 2011 at 3:49 AM, Olle E. Johansson <[email-masked]> wrote:

> If you support DTMF in RTP you already have a requirement that you SHOULD
>  only do that over SRTP. If rtcweb supports telephony-events, we are
> already on the SRTP side as almost mandatory. I think it's easier to reach
> an agreement on SRTP being mandatory than DTMF being dis-allowed.
>
>
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.

Also, I wanted expand on the debug requirements: I do hope we will make key
exchange mechanism, different from SDES, mandatory for WebRTC. Passing
actual encryption keys through JavaScript makes media encryption to easy to
circumvent. This means some type of public/private key encryption used for
key exchange. If we do this right, getting to the actual key used for media
session encryption will be very difficult, so most of the tools currently
used for SRTP debugging will stop working. We will also end up with
something new, which will mean extensive need for debugging. Ability to
turn this component on and off will be very helpful for implementation
debugging. Once again, this will probably be not a critical point, but
making something easier for developers usually goes a long way in driving
the adoption.

One more benefit of having RTP as fallback for legacy interop is that it
will allow us to specify something that will be more secure for WebRTC. If
SDES support would no longer be needed, we can concentrate on using key
exchange mechanism that is actually secure.

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.
_____________
Roman Shpount

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 11 Nov 2011 13:38:05 +0000

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

---

From: Roman Shpount <[email-masked]>
Date: Fri, 11 Nov 2011 09:58:43 -0500

> I think using in-band tones in RTP for DTMF instead of 4733 would be a
This is not what I've said. What I said was that the rest of the industry
is using AVT tones (RFC 2833/4733) compliant DTMF tones without SRTP and
normally does not force SRTP if you plan to use RFC 2833 tones. Even though
there is a SHOULD requirement for SRTP in conjunction with RFC 4733, the
industry ignores it as being excessive and uses RFC 4733 tones in plain
RTP, which is what I am suggesting. Not using SRTP does not mean that we
need to switch to in band tones.
_____________
Roman Shpount

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 11 Nov 2011 07:14:40 +0800

On Nov 10, 2011, at 13:19 , Ravindran, Parthasarathi wrote:

> AFAIK in case of telepresence or equivalent endpoint, it requires the special hardware to encrypt/decrypt the whole bunch of media from it. 

Really? For a fairly high end 3 screenTP systems, it's like a 6 mbps stream. I seem to recall a linksys router with VPN could do crypto at that rate. Been awhile since I looked at the numbers so perhaps I have this all wrong.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 11 Nov 2011 06:59:13 -0800

> On Fri, Nov 11, 2011 at 3:49 AM, Olle E. Johansson <[email-masked]> wrote:
o, I wanted expand on the debug requirements: I do hope we will make key
> used for SRTP debugging will stop working.

This simply isn't "very difficult". There are existing tools for doing SSL/TLS
diagnostics and for recovering the encrypted data (e.g., ssldump, wireshark)
and it's not going to be hard to adapt them to this application.

> exchange mechanism that is actually secure.

I think it's important to distinguish between legacy interop and WebRTC-WebRTC
cases. I'm more positive (though still not exactly thrilled) about the
claim that we
should support RTP for interop modes provided that WebRTC-WebRTC calls are
secure.

> 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.

There's no real need for additional verification of the remote party at the ICE
level. My suspicion is that the RTTs won't be a significant factor here, but
certainly it would be possible to embed the DTLS messages into the
ICE exchange if it turned out to be.

-Ekr

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 11 Nov 2011 16:52:20 +0000

I think it's a SHOULD implement, but that's not the same as MUST *use*.  ( though it may have meant SHOULD use)

Regardless, I don't see what that has to do with this SRTP topic.  Clearly DTMF is used in cases where privacy is important since it often represents PINs.

-Hadriel

Sent from my iPhone

On Nov 11, 2011, at 9:58 AM, "Roman Shpount" <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Nov 11, 2011 at 8:38 AM, Hadriel Kaplan <[email-masked]<mailto:[email-masked]>> wrote:

This is not what I've said. What I said was that the rest of the industry is using AVT tones (RFC 2833/4733) compliant DTMF tones without SRTP and normally does not force SRTP if you plan to use RFC 2833 tones. Even though there is a SHOULD requirement for SRTP in conjunction with RFC 4733, the industry ignores it as being excessive and uses RFC 4733 tones in plain RTP, which is what I am suggesting. Not using SRTP does not mean that we need to switch to in band tones.
_____________
Roman Shpount

---

From: Randell Jesup <[email-masked]>
Date: Fri, 11 Nov 2011 13:45:55 -0500

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

+10.  Let's not even discuss that option further.

> 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 wor…

Anything we can do to minimize clipping and reduce startup RTTs is a 
*very* good thing.  We should start seriously analyzing this as we're 
getting down to more specifics.

And recent privacy breaches have shown that otherwise-good pre-warming 
of connections and pre-negotiation of codecs may be problematic from a 
security point of view - exchanging ICE candidates with an incoming 
OFFER from your abusive ex-boyfriend might tell them where you are 
(local IP), though it would be possible for people not wanting to 
disclose their address to *require* a TURN proxy be in use and not offer 
local IP, limiting the leaked information.  This does require proactive 
selection of safety by the user, a risky proposition.

As a possible compromise, you could force TURN for the pre-start of the 
call and if accepted, renegotiate with real local addresses.  Might 
cause a glitch though if you're not careful.

-- 
Randell Jesup
[email-masked]

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Fri, 11 Nov 2011 12:55:43 -0600

On 11/11/2011 12:45 PM, Randell Jesup wrote:

> call and if accepted, renegotiate with real local addresses. Might cause
> a glitch though if you're not careful.

Given that the new 'standard' for voice communications quality appears 
to be whatever a CDMA/GSM/etc. cellular network can provide, this sort 
of glitch would probably go unnoticed by a large percentage of users :-)

-- 
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: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 13 Nov 2011 12:38:22 +0100

2011/11/11 Hadriel Kaplan <[email-masked]>:
> WebRTC browsers need to be able to send DTMF out

Why??? WebRTC is not SIP, this is not about legacy telephony. If
somebody creates a NEW RTC protocol it would not include
like-DTMF's-over-RTP anymore. DTMF is an ugly and annoying mechanism
from the past, there is no need at all to incorporate it in a new
specification (unless the only "innovation" telcos have in mind are
"calls from the Web to a PSTN IVR sytem"). DMTF's are symbols (0-9, *,
#, A-F) to be sent over the media flow. It's really ugly and just a
reminiscence from the old PSTN.

No, please, forget DTMF's. No more "SIP" nor "PSTN" in this WG.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 13 Nov 2011 12:02:40 +0000

> No, please, forget DTMF's. No more "SIP" nor "PSTN" in this WG.

First, DMTFs aren't just about SIP - it's used by other protocols as well.
But yes obviously it's about enabling WebRTC browsers to communicate with non-WebRTC peers, including those in SIP, such as IVRs and voicemail servers and so on - not just in "Telco's" but also in Enterprises.

Some people in this WG don't want to worry about that, which is fine - don't worry about it.  If you don't want to use RFC4733, your Javascript/Server code doesn't have to worry about it.  But some people in this WG *do* want to support interworking with other deployed devices/domains.  So long as the mechanisms needed to do so don't hurt WebRTC or force a specific architectural model, why do you care?

-hadriel

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 13 Nov 2011 13:28:20 +0100

2011/11/13 Hadriel Kaplan <[email-masked]>:
> So long as the mechanisms needed to do so don't hurt WebRTC or force a specific architectural model, why do you care?

Some telcos in this WG (and I could find exact mails) would accept
even if WebRTC uses a pure SIP stack. Some others propose G729
inclusion in WebRTC (wow!), and all of them ask for non mandatory
SRTP. Soon, they will also ask non mandatory ICE (they will argue "ICE
mandatory to implement in WebRTC client, but not mandatory to use").
DTMF's via RTP is just the less important subject. What I care is all
the rest, and the fact that 75% of mails in this WG are about PSTN
legacy interoperability.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Sun, 13 Nov 2011 13:59:12 +0000

>> AFAIK in case of telepresence or equivalent endpoint, it requires the
>special hardware to encrypt/decrypt the whole bunch of media from it.
>
>Really? For a fairly high end 3 screenTP systems, it's like a 6 mbps
>stream.

<partha> AFAIK, ~15Mbps is very much possible for 3 screen TP and one of 
the related link is http://www.nojitter.com/blog/225400682. I come to
know about these numbers during SBC development to interop with 
telepresence. May be multiple variant of TP exists </partha>

 I seem to recall a Linksys router with VPN could do crypto at
>that rate. Been awhile since I looked at the numbers so perhaps I have
>this all wrong.

<partha> In fact, I started thinking in this line based on your 
point on SIPREC requirement not to mandate separate SRTP keys for 
telepresence recording & communication session and it was accepted in
SIPREC. </partha>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 13 Nov 2011 14:01:14 +0000

On Nov 13, 2011, at 7:28 AM, Iñaki Baz Castillo wrote:

> even if WebRTC uses a pure SIP stack.

I'm not sure we have the same understanding of the word "telco".  A "telco" for me is a telephone-company/telecommunications provider/communications service provider (wireless, landline, cable MSOs, etc.).  As far as I can tell, of the 482 members of this mailing list, there are about 32 with email addresses that imply they work for "telcos", and none of them have advocated embedding a SIP stack in the browser.  Lots of people on this mailing list work for companies that sell products to "telco's", but most of them do not advocate putting a SIP stack in the browser either.[1]

Also I really think you're being unfair to people who work for telco's.  I have personally spoken off-line with several of the "telco's" that monitor this mailing list, and all of them believed that whatever's needed to interwork to non-WebRTC must not hurt/degrade WebRTC.  For example most of them actually *want* SRTP to be used, and even think ICE is needed.  Of course they would also prefer to be able to interface to WebRTC with as least cost/complexity as possible, but they know it's not all going to be possible.

> and all of them ask for non mandatory
> SRTP.

I don't think that's a fair assessment.  I don't recall a single one of the people who work for telco's ask for non-mandatory SRTP, and even if one did he/she does not represent "all of them".

> Soon, they will also ask non mandatory ICE (they will argue "ICE
> the rest,

But DTMF was the topic of the email.

> and the fact that 75% of mails in this WG are about PSTN
> legacy interoperability.

No, they're not.  75% might be about SIP-related interoperability, but SIP is not just the PSTN.  The SRTP/RTP debate, for example, is not about the PSTN.  The forking debate is not about the PSTN.  The ICE and media consent debates were about both PSTN and Enterprise SIP.  The ROAP vs. real API debate was not about the PSTN nor even SIP.  The congestion control threads were not either.  The TURN URI scheme thread is not about it.  The data channel thread is not about it.  ...

-hadriel

---

From: Justin Uberti <[email-masked]>
Date: Sun, 13 Nov 2011 09:24:18 -0500

On Sun, Nov 13, 2011 at 7:02 AM, Hadriel Kaplan <[email-masked]>wrote:

> But yes obviously it's about enabling WebRTC browsers to communicate with
> non-WebRTC peers, including those in SIP, such as IVRs and voicemail
> servers and so on - not just in "Telco's" but also in Enterprises.
>
> Some people in this WG don't want to worry about that, which is fine -
> don't worry about it.  If you don't want to use RFC4733, your
> Javascript/Server code doesn't have to worry about it.  But some people in
> this WG *do* want to support interworking with other deployed
> devices/domains.  So long as the mechanisms needed to do so don't hurt
> WebRTC or force a specific architectural model, why do you care?
>

As a non-"telco" participant in this WG, I strongly agree with this. DTMF
has a clear upside (support for PSTN) and no downside other than the need
for a new API method.

---

From: Miguel Casas-Sanchez <[email-masked]>
Date: Sun, 13 Nov 2011 19:46:57 +0100

İt is indeed very interesting to have interoperability with loads of
systems, but that should (personal opinion) be left to the applications,
and not be suggested in a standard that everyone will need to parse. So:
keep standard lean would be my vote (=leave dtmf out) try and focus on
mandatory and really nice-to-have features.
Miguel

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 13 Nov 2011 17:50:00 -0500

On 11/13/2011 01:46 PM, Miguel Casas-Sanchez wrote:
> İt is indeed very interesting to have interoperability with loads of systems,
> but that should (personal opinion) be left to the applications, and not be
> suggested in a standard that everyone will need to parse. So: keep standard lean
> would be my vote (=leave dtmf out) try and focus on mandatory and really
> nice-to-have features.
> Miguel

I do not know why you and others are singling out DTMF.  I am no fan of building
stuff around carriers needs myself, but DTMF is a codec, no more, no less.  Even
the fast codec switching mechanism is not special - comfort noise use it too,
and a system that would recognize music and dynamically switch between audio and
MIDI would probably be considered innovative.

> 
> On Nov 13, 2011 3:24 p.m., "Justin Uberti" <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>     On Sun, Nov 13, 2011 at 7:02 AM, Hadriel Kaplan <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
> 
>         But yes obviously it's about enabling WebRTC browsers to communicate
>         with non-WebRTC peers, including those in SIP, such as IVRs and
>         voicemail servers and so on - not just in "Telco's" but also in Enterprises.
> 
>         Javascript/Server code doesn't have to worry about it.  But some people
>         in this WG *do* want to support interworking with other deployed
>     [email-masked] <mailto:[email-masked]>

-- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Tim Panton <[email-masked]>
Date: Mon, 14 Nov 2011 08:30:40 +0000

> MIDI would probably be considered innovative.

Which gives further weight to my argument that we should be exposing the codec
as  a javascript object , the we could have a generic 'notification from this codec instance'
callback, instead of doing all these legacy hacks as one-off special cases.

Tim.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 14 Nov 2011 16:38:19 +0800

> callback, instead of doing all these legacy hacks as one-off special cases.
what would the codec object represent?

The currently proposed API presents a MediaStreamTrack object.
How would a codec object relate to the MediaStreamTrack object?

(this is an api discussion, so probably belongs on the W3C list)

                Harald

---

From: Neil Stratford <[email-masked]>
Date: Mon, 14 Nov 2011 08:39:03 +0000

> has a clear upside (support for PSTN) and no downside other than the need

This is my concern, that we are proposing a codec specific API method when
we have ruled out exposing APIs for other codecs.

If two peers have negotiated a data channel between them it doesn't make a
lot of sense to send DTMF over RTP, it should be carried over the reliable
data channel. So if we do expose an API for sending tones, can it be done
in such a way that it can be carried using whatever the most appropriate
transport is? (obviously without requiring any javascript changes - because
we can't expect javascript developers to upgrade)

Neil

---

From: Justin Uberti <[email-masked]>
Date: Mon, 14 Nov 2011 04:13:54 -0500

> we can't expect javascript developers to upgrade)
If two peers have negotiated a data channel, it doesn't make sense to use
DTMF at all. I can see the converse argument to make the DataStream API use
DTMF if it is the only thing available, in order to avoid adding a
DTMF-specific API, but I think the semantics are different enough that the
DTMF API is a better approach.

Regarding whether this API should be extended to be a generic codec API, I
think it should be obvious that the ability to send one of 12 well-defined
signals in a standardized manner is orders of magnitude simpler than the
configuration options available for modern video codecs.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 14 Nov 2011 10:53:17 +0100

> I'm not sure we have the same understanding of the word "telco".  A "telco" for me is a telephone-company/telecommunications provider/communications service provider (wireless, landline, cable MSOs…

Ok, let me say that with the world "telco" I include
telephony/telecommunications companies, telephony vendors (phones,
PBXs, SBCs, gateways, softswitches...) and anyone with real interest
in interoperability with existing SIP and/or PSTN networks.

> Also I really think you're being unfair to people who work for telco's.  I have personally spoken off-line with several of the "telco's" that monitor this mailing list, and all of them believed tha…

My concern is that 75% of the traffic in this maillist is about making
WebRTC capable to accomplish with SIP/PSTN requirements. And that is
not so bad, but what is really bad is that there is no more. Nobody is
proposing things that are currently unfeasible with SIP, so we are
limiting the posibilities of WebRTC to those provided by SIP protocol.
The vision/scope of WebRTC is currently limited to what SIP provides.
I would like to hear proposals that are out of the scope of the pure
telephony, but those proposals won't came from telcos (see the
"definition" above) since telcos have never succeeded in the Web.

> But DTMF was the topic of the email.

RTP/SRTP is unreliable so sending like-reliable information (DTMF's)
over an unreliable stream is, for sure, not the best design. In WebRTC
such reliable info could be sent over signaling or over the
data-channel (both of them reliable). Why to choose the worst option?
reply: to interoperate with existing VoIP protocols.

> No, they're not.  75% might be about SIP-related interoperability, but SIP is not just the PSTN.  The SRTP/RTP debate, for example, is not about the PSTN.

The SRTP/RTP debate is about interoperability with PSTN or SIP
networks, isn't it? The best argument I've read is "upgrading telco's
devices is too expensive so plain RTP is desired".

SRTP is cheap and easy to implement in a fresh deployment. Mandating
SRTP has not the same inplications as mandating HTTPS (server
certificates and so) so those arguments about "HTTPS is not mandatory
so neither SRTP" are just a good excuse IMHO.

>The forking debate is not about the PSTN.  The ICE and media consent debates were about both PSTN and Enterprise SIP.  The ROAP vs. real API debate was not about the PSTN nor even SIP.  The congestion control threads were not either.  The TURN URI scheme thread is not about it.  The data channel thread is not about it.  ...

Well, let's see what happens. I still think that we need some crazy
pure Web folks in this WG (not too much or we'll have proposals about
using port TCP 80 for sending RTP). ;)

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Neil Stratford <[email-masked]>
Date: Mon, 14 Nov 2011 10:16:33 +0000

On Mon, Nov 14, 2011 at 9:13 AM, Justin Uberti <[email-masked]> wrote:
>> On Sun, Nov 13, 2011 at 2:24 PM, Justin Uberti <[email-masked]>wrote:
>>
>>>
>>> As a non-"telco" participant in this WG, I strongly agree with this.
>>> DTMF has a clear upside (support for PSTN) and no downside other than the
>>> need for a new API method.
>>>
>>
>> This is my concern, that we are proposing a codec specific API method
>> when we have ruled out exposing APIs for other codecs.
>>
>> If two peers have negotiated a data channel between them it doesn't make
>> a lot of sense to send DTMF over RTP, it should be carried over the
>> reliable data channel. So if we do expose an API for sending tones, can it
>> be done in such a way that it can be carried using whatever the most
>> appropriate transport is? (obviously without requiring any javascript
>> changes - because we can't expect javascript developers to upgrade)
>>
>>
> DTMF at all.

If a WebRTC capable media server is relaying media to the PSTN you may
still want to signal some kind of DTMF between the client and the media
server for onward relay. If the data channel is available, why not use it
for DTMF? Should the DTMF API only be for RFC4733 and not any other
transport?

> configuration options available for modern video codecs.

I still see a benefit in exposing codec parameters, and in providing codecs
with the ability to generate events. Imagine I was building an n-way video
conference solution based on a scalable video codec, with a central point
transrating each stream based on the active speaker. Receiving codec events
in the javascript would enable me to detect rate changes and re-render the
display appropriately without requiring a full renegotiation each time.

Neil

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 14 Nov 2011 18:23:02 +0800

On 11/14/2011 05:53 PM, Iñaki Baz Castillo wrote:
> not so bad, but what is really bad is that there is no more.

Inaki,

out of the last 903 messages on the list, 151 of them (approximately 1 
of 6) were written by you.
Many, many of your messages are about SIP.
Perhaps if you did not talk so much about SIP, there would be more room 
for the "other stuff" that you miss so much?

                         Harald

---

From: Wolfgang Beck <[email-masked]>
Date: Mon, 14 Nov 2011 18:37:16 +0800

If I recall this correctly, the DTMF payload type was made for a
specific scenario:
1. an analogue phone is connected to a (SIP) device
2. the user presses a key on her phone during a call.
3. The device detects the tone generated by the phone. Relaying it out
of band with some SIP message can lead to undesired effects: a bit of
the DTMF might have escaped the SIP device, was sent as G.711, and was
detected by the remote PSTN party. Now if the SIP message (eg INFO)
arrives and gets translated by a SIP-PSTN gateway into a DTMF tone,
the remote party will see two DTMF events instead of one.

The DTMF payload solves this.

As long as we don't want to attach POTS phones to the browser, outband
signalling of events should be sufficient. If we do connect POTS lines
to the browser, we have to talk about fax as well. Thankfully, modem
ports have disappeared from today's laptops and PCs.

Wolfgang Beck

---

From: Justin Uberti <[email-masked]>
Date: Mon, 14 Nov 2011 05:39:57 -0500

On Mon, Nov 14, 2011 at 5:16 AM, Neil Stratford <[email-masked]>wrote:

> for DTMF?

Why represent the DTMF in an alternate format, when the only thing that
cares about it wants it in RFC 4733?

>  Should the DTMF API only be for RFC4733 and not any other transport?
>

That's my thinking.

>
>
>> Regarding whether this API should be extended to be a generic codec API,
>> I think it should be obvious that the ability to send one of 12
>> well-defined signals in a standardized manner is orders of magnitude
>> simpler than the configuration options available for modern video codecs.
>>
>
> I still see a benefit in exposing codec parameters, and in providing
> codecs with the ability to generate events. Imagine I was building an n-way
> video conference solution based on a scalable video codec, with a central
> point transrating each stream based on the active speaker. Receiving codec
> events in the javascript would enable me to detect rate changes and
> re-render the display appropriately without requiring a full renegotiation
> each time.
>

It's not hard for me to imagine that scenario, but I don't understand how a
codec API is needed to allow UI relayout on stream resolution change.

---

From: Neil Stratford <[email-masked]>
Date: Mon, 14 Nov 2011 10:50:57 +0000

On Mon, Nov 14, 2011 at 10:39 AM, Justin Uberti <[email-masked]> wrote:

>> On Mon, Nov 14, 2011 at 9:13 AM, Justin Uberti <[email-masked]>wrote:
>>>
>>>> If two peers have negotiated a data channel between them it doesn't
>>>> make a lot of sense to send DTMF over RTP, it should be carried over the
>>> If two peers have negotiated a data channel, it doesn't make sense to
>>> use DTMF at all.
>>>
>>

Only a SIP destination endpoint would want it in RFC 4733, a PSTN endpoint
is going to want it in-band in the media stream, which the relaying media
server from WebRTC to PSTN would likely do. (No SIP here.)

> It's not hard for me to imagine that scenario, but I don't understand how
> a codec API is needed to allow UI relayout on stream resolution change.
>

How today am I notified of a quality or resolution change in the decoded
incoming video stream? What I want to avoid is the use of an external
signalling mechanism to tell me this, so I can avoid the glitchy
resize-before-ready - I want to do it when the data really is at the new
resolution.

Neil

---

From: Justin Uberti <[email-masked]>
Date: Mon, 14 Nov 2011 06:07:19 -0500

On Mon, Nov 14, 2011 at 5:50 AM, Neil Stratford <[email-masked]>wrote:

> On Mon, Nov 14, 2011 at 10:39 AM, Justin Uberti <[email-masked]>wrote:
>

This is a RTP thing, not a SIP thing. The PSTN gateway will take RTP as
input, including RFC 4733 telephone-event.

>>>> Regarding whether this API should be extended to be a generic codec
>>>> API, I think it should be obvious that the ability to send one of 12

Agreed. The <video/> element has videoWidth/videoHeight properties, but it
doesn't appear that a callback exists to indicate changes, so we'll
probably need to make a new API here.

Note though that no signaling is required for this case.

---

From: Neil Stratford <[email-masked]>
Date: Mon, 14 Nov 2011 11:48:22 +0000

On Mon, Nov 14, 2011 at 11:07 AM, Justin Uberti <[email-masked]> wrote:

>> Only a SIP destination endpoint would want it in RFC 4733, a PSTN
>> endpoint is going to want it in-band in the media stream, which the
>> relaying media server from WebRTC to PSTN would likely do. (No SIP here.)
>>
>

In my example the terminating WebRTC media server *is* the PSTN gateway.
There is no RTP beyond the gateway, just ISDN etc. In this case to get the
most reliable DTMF transport from the client to the PSTN I'd have to roll
my own DTMF transport over a DataStream, carry if over the signalling
channel, or accept the lossy RTP DTMF channel. In many cases this DTMF RTP
will be the only RTP sent in that direction - I'm often asked for the
ability to send DTMF without requesting microphone access permission for
information only IVR use cases.

I'd prefer we didn't have a DTMF API and instead leave it up to the
developer to send over the signalling channel (the usual sync arguments
don't apply here if you are sending from an API), but if we do have an API
it makes sense to use the most reliable transport available to carry it.

> Note though that no signaling is required for this case.

I agree that no signalling is required, but I'm not sure that a simple
callback with width/height is enough to enable notification of quality
changes etc. I still think that to build telepresence/broadcast quality
systems we will need closer access to both codec parameters and codec state
changes.

Neil

---

From: Justin Uberti <[email-masked]>
Date: Mon, 14 Nov 2011 07:08:19 -0500

On Nov 14, 2011 7:48 PM, "Neil Stratford" <[email-masked]> wrote:
>>>>>> If two peers have negotiated a data channel, it doesn't make sense
to use DTMF at all.
>>>>>
>>>>>
>>>>> If a WebRTC capable media server is relaying media to the PSTN you
may still want to signal some kind of DTMF between the client and the media
server for onward relay. If the data channel is available, why not use it
for DTMF?
>>>>
>>>>
>>>> Why represent the DTMF in an alternate format, when the only thing
that cares about it wants it in RFC 4733?
>
>>> How today am I notified of a quality or resolution change in the
decoded incoming video stream? What I want to avoid is the use of an
external signalling mechanism to tell me this, so I can avoid the glitchy
resize-before-ready - I want to do it when the data really is at the new
resolution.
>>
>>
>> Agreed. The <video/> element has videoWidth/videoHeight properties, but
it doesn't appear that a callback exists to indicate changes, so we'll
probably need to make a new API here.

I'm sure we will need to expose more info, but I think that should be
driven by specific requirements, like what you mention above.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 14 Nov 2011 12:38:32 +0000

On Nov 14, 2011, at 6:48 AM, Neil Stratford wrote:

> In my example the terminating WebRTC media server *is* the PSTN gateway. There is no RTP beyond the gateway, just ISDN etc. In this case to get the most reliable DTMF transport from the client to the PSTN I'd have to roll my own DTMF transport over a DataStream, carry if over the signalling channel, or accept the lossy RTP DTMF channel. In many cases this DTMF RTP will be the only RTP sent in that direction - I'm often asked for the ability to send DTMF without requesting microphone access permission for information only IVR use cases.

If you create your own media server, you can do whatever you want - you don't need the IETF for anything.  I mean you can open a SCTP/DTLS/UDP data-channel and send whatever you want over it; or you can open a websocket to it and send whatever you want over it, etc.  Why would you even use "DTMF" for that - i.e., why would you constrain yourself to only a few digits/characters?

The only reason to have "DTMF" as true "DTMF" a la rfc4733 is to be able to use media-servers created from other vendors/third-parties, possibly not even managed/owned by the same domain as WebRTC is running in.  But for that to work, it needs to be based on a standard.  The only two IETF standards for that today are KPML and RFC4733.  And if we want it to be based on a standard most media-servers actually implement, that would be RFC4733.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 14 Nov 2011 14:02:12 +0100

Hi,

> proposing things that are currently unfeasible with SIP, so we are
l> imiting the posibilities of WebRTC to those provided by SIP protocol.
> The vision/scope of WebRTC is currently limited to what SIP provides.

People in this WG seem to make a default assumption that SIP restricts people from doing new cool things, "prevents innovation" etc.

But, maybe SIP actually CAN be used to do what people (or, at least 75% of them) want. Maybe SIP isn't such a bad protocol after all - which would be good news for those of us who have been working with it for a decade :)

Regards,

Christer

---

From: Neil Stratford <[email-masked]>
Date: Mon, 14 Nov 2011 13:29:16 +0000

On Mon, Nov 14, 2011 at 12:38 PM, Hadriel Kaplan <[email-masked]>wrote:

> If you create your own media server, you can do whatever you want - you
> don't need the IETF for anything.  I mean you can open a SCTP/DTLS/UDP
> data-channel and send whatever you want over it; or you can open a
> websocket to it and send whatever you want over it, etc.  Why would you
> even use "DTMF" for that - i.e., why would you constrain yourself to only a
> few digits/characters?
>

I'd constrain myself because that's all I can forward on over the PSTN to
the remote IVR. If the 'IVR' was implemented using the WebRTC media server
I'm sure the control channel wouldn't restrict itself to a few digits.

> The only reason to have "DTMF" as true "DTMF" a la rfc4733 is to be able
> to use media-servers created from other vendors/third-parties, possibly not
> even managed/owned by the same domain as WebRTC is running in.  But for
> that to work, it needs to be based on a standard.  The only two IETF
> standards for that today are KPML and RFC4733.  And if we want it to be
> based on a standard most media-servers actually implement, that would be
> RFC4733.

RFC4733 is fine, I was just arguing that if you have a better transport for
DTMF available than RTP it seems a shame not to use it, especially given we
don't have the usual timing/sync problem as the DTMF can only be generated
via an API. I guess in the Javascript application we'll have to figure out
if the remote peer is happy to receive DTMF over DataStream via the
signalling channel, and then implement a different sendDigit() function. I
may be alone in having had bad experiences with DTMF RTP reliability.

If we support outbound DTMF, should we support inbound DTMF as well, so I
can write an IVR in a WebRTC browser? (eg. think calling to control a
webcam that is streaming from a browser) Should it fire events to the
javascript on a DTMF digit being received?  What about continuation events,
one event for the start and repeats until it finishes? What should play the
local DTMF tone - should it be implicit in the API, or do we need a tone
generator that can be invoked?

Neil

---

From: Roman Shpount <[email-masked]>
Date: Mon, 14 Nov 2011 09:49:02 -0500

> it makes sense to use the most reliable transport available to carry it.

Even if WebRTC is not going to support RFC 4733 DTMF (I am not saying it
should not. I would strongly prefer it did.), we still need to deal with
timing sync between commands and media content. Imagine an application
which asks to press "Done" after recording is complete. If there is no
timing sync, "Done" command can arrive plus/minus half a second from the
end of an actual recording. This makes a lot of applications, like record a
greetings almost unusable. I think that even if WebRTC will support DTMF,
it would be useful to have some type of API which will allow to time sync
arbitrary signaling messages with media stream. One option would be to give
JavaScript access to media stream time stamp. Another option (less
preferred from my point of view) is to have a separate RTP payload that can
be used to transport arbitrary application messages.
_____________
Roman Shpount

---

From: Randell Jesup <[email-masked]>
Date: Mon, 14 Nov 2011 10:09:44 -0500

On 11/14/2011 3:39 AM, Neil Stratford wrote:
> On Sun, Nov 13, 2011 at 2:24 PM, Justin Uberti <[email-masked]
>     DTMF has a clear upside (support for PSTN) and no downside other
>     than the need for a new API method.
>
>

Well, "codec" is a very strong word for RFC 4733 (though you can argue 
it's pedantically correct, and see below for why it's actually not a bad 
description in a way).

> reliable data channel. So if we do expose an API for sending tones, can
> it be done in such a way that it can be carried using whatever the most

RFC 4733 is similar to a "Partially-reliable realtime data stream with a 
limited vocabulary" - basically (typically) around 4-5 bits plus timing 
info.  However...

This is somewhat distinct from the data channels in WebRTC, though it 
might fit in there once we choose a data solution.  The problem is that 
the data solution may not match the needs of DTMF (though perhaps that 
speaks to the requirements for the data section).  Right now partial 
reliability isn't required, and would be needed OR the application would 
have to use unreliable and duplicate much of the details of RFC 4733. 
In general, we've discussed in generalities prioritization of data vs. 
media, but there's no guaranteed delivery speed for a data channel vs. a 
media channel.

However, even if you can deliver it out-of-band via a data channel, it 
wouldn't have a shared timebase (and synchronized playback) - an area 
where the 'codec' description fits better.  DTMF in terms of 4733 really 
is a media stream, just a partially-reliable one.  Ignoring 
compatibility, I would have no problem with defining it as a separate 
media stream (m= line in SDP speak) which is part of a synchronization 
group with the normal audio streams.  However, given 'normal' RTP audio 
receivers generally are already designed to handle RFC 4733, there's 
little advantage to going with a separate stream.  There might be other 
uses for such a parallel media stream, of course.

The question is how much need is there in WebRTC for a 
media-synchronized, partially-reliable data channel outside of the 
current RFC 4733 definitions?  If there is a need, we could define a use 
(or perhaps superset) of RFC 4733 that allows wider application use, in 
place of or in addition to the current RFC uses/codes.

If media synchronization isn't needed, then a data channel may do 
(depending on the data spec agreed to).

-- 
Randell Jesup
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Mon, 14 Nov 2011 10:34:11 -0500

> reply: to interoperate with existing VoIP protocols.

Note my other email I just sent - DTMF has a property not shared by the 
data streams - media synchronization.  I won't repeat all the arguments 
here, but there actually is a reason for delivering it in a media 
channel, totally regardless of legacy.  For a greenfield design, one 
*might* implement it as a separate media stream (m= line), but even 
there I'm not sure I would mandate it be separated.

-- 
Randell Jesup
[email-masked]

---

From: Neil Stratford <[email-masked]>
Date: Mon, 14 Nov 2011 15:47:11 +0000

On Mon, Nov 14, 2011 at 3:34 PM, Randell Jesup <[email-masked]>wrote:

> here, but there actually is a reason for delivering it in a media channel,
> totally regardless of legacy.  For a greenfield design, one *might*
> implement it as a separate media stream (m= line), but even there I'm not
> sure I would mandate it be separated.

How can we achieve the media synchronization in WebRTC? In a traditional
RTC endpoint the DTMF comes from the same source as the media, in many
cases it's actually taken from the media itself. However in WebRTC the only
way to trigger a DTMF event is through an asynchronous Javascript function
call, which is not synchonized to the media. Do we assume that the function
call happens 'at about the right time' and take that as the current
timestamp to use?

---

From: Randell Jesup <[email-masked]>
Date: Mon, 14 Nov 2011 10:58:09 -0500

On 11/14/2011 10:47 AM, Neil Stratford wrote:
> On Mon, Nov 14, 2011 at 3:34 PM, Randell Jesup <[email-masked] wrote:
>     Note my other email I just sent - DTMF has a property not shared by
>     the data streams - media synchronization.  I won't repeat all the
>     arguments here, but there actually is a reason for delivering it in
>     a media channel, totally regardless of legacy.  For a greenfield
>     design, one *might* implement it as a separate media stream (m=
>     line), but even there I'm not sure I would mandate it be separated.
>
>
> cases it's actually taken from the media itself. However in WebRTC the
> only way to trigger a DTMF event is through an asynchronous Javascript
> function call, which is not synchonized to the media. Do we assume that
> the function call happens 'at about the right time' and take that as the
> current timestamp to use?

That speaks to the API needing tweaking - the JS app generally knows 
*when* (in realtime) the event occurred; it should pass that info in 
with the command to send it so the synchronized data can be correctly 
generated (along with the other timing info - duration or ongoing until 
told to stop).  ("When" could also include a special case for "now", 
defined as the current media clock position when the function call is 
processed.)

-- 
Randell Jesup
[email-masked]

---

From: Michael Thornburgh <[email-masked]>
Date: Mon, 14 Nov 2011 11:12:35 -0800

in "those proprietary plugins" that nobody ever namesFlash, media streams have a generic data channel that is time synchronized to the media. calling the "send" method on a publishing-to-peers-or-server stream puts the current media timestamp on the message. at the subscriber end the callback associated with the message is called synchronized with the playback media clock.

this is useful for example when recording and playing back the non-media parts of an online meeting, such as text messages or slide changes, or insertion of cue points in media, or text captions, or etc.

in Those Proprietary Plugins That Must Not Be Named, the data channel of a stream can be fully reliable or partially reliable. the timing semantics for a time-synchronized data message is that it won't trigger its callback before its timestamp, but if it will trigger if it arrives late (which might happen for a fully reliable message).

-mike

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 15 Nov 2011 08:42:54 +0800

On 11/7/11 11:58 AM, Roman Shpount wrote:
> experience regarding real-time communications, but for many reasons 
> most of this experience is related to SIP. Based on this, experience 
> we know that there are issues, such as glare, media forking, media 
> negotiation, support of future codecs, that need to be addressed.

Or not.

> If we are asking about scenarios which have not been relevant to your 
> particular "innovative" application, it does not mean that other users 
> of WebRTC will not encounter it. This is all about creating the best 
> possible future proof system we can.

The best possible future-proof system would be one that exposes 
low-level access to the primitives needed to construct anything. That is 
not, unfortunately, what is currently proposed.

>
> Second, the reason I raised my comment about SRTP was exactly in order 
> to support future applications that we are not aware about now. I do 
> not see a why we should mandate something without a good reason. The 
> more control we will give to developer, the more applications it would 
> be possible to build. I would strongly support required to implement, 
> but not required to use model for SRTP. This way SRTP is available to 
> the application developer but not something they must use. There are 
> places where communications are illegal, unless they can be 
> intercepted by the "big brother". Things like Skype are illegal there 
> for this exact reason. I would not argue if this situation is 
> appropriate, legal, or moral, but it exists. It would be better that 
> WebRTC would be able to operate in environments like this.

Do you want *your* browser to be able to switch to plain RTP for the 
call you're making from a place with an unsecured wi-fi network (as 
essentially all are at this point, given the ease of cracking the 
typical schemes used for wireless security these days) ?

I don't. Even though I do agree that there might be external reasons why 
service providers might want the browser to have that ability.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 15 Nov 2011 08:44:33 +0800

On 11/7/11 11:50 PM, Iñaki Baz Castillo wrote:
> 2011/11/7 Wolfgang Beck<[email-masked]>:
>
Why *wouldn't* you want the JavaScript client code to participate in 
this decision?

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 15 Nov 2011 08:52:53 +0800

(Editing the subject line, again, to note that we have strayed far far 
off the original topic)

On 11/14/11 11:47 PM, Neil Stratford wrote:
> How can we achieve the media synchronization in WebRTC? In a 
> traditional RTC endpoint the DTMF comes from the same source as the 
> media, in many cases it's actually taken from the media itself. 
> However in WebRTC the only way to trigger a DTMF event is through an 
> asynchronous Javascript function call, which is not synchonized to the 
> media. Do we assume that the function call happens 'at about the right 
> time' and take that as the current timestamp to use?

This actually raises a higher-level question of whether or not it is 
possible to deliver arbitrary *synchronized* data alongside audio and 
video. There is an argument that this is the domain of something like 
"timed text track" and *not* a WebRTC-specific behavior of the side data 
channel we've been talking about.

I have an application that currently uses <that proprietary plugin we 
don't talk about> to deliver streaming audio along with timecode that 
can be displayed in-sync with the audio that I would love to run inside 
a browser without <that plugin>.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 15 Nov 2011 08:55:51 +0800

(Yet again editing the subject line)

On 11/14/11 8:38 PM, Hadriel Kaplan wrote:
> The only reason to have "DTMF" as true "DTMF" a la rfc4733 is to be 
> able to use media-servers created from other vendors/third-parties, 
> possibly not even managed/owned by the same domain as WebRTC is 
> running in. But for that to work, it needs to be based on a standard. 
> The only two IETF standards for that today are KPML and RFC4733. And 
> if we want it to be based on a standard most media-servers actually 
> implement, that would be RFC4733.

Agreed. There are use cases for which it is necessary to have the 
browser insert RFC4733 DTMF in the media channel, rather than sending 
arbitrary events to the HTTP / signaling server.

This should be a requirement.

Matthew Kaufman

---

From: Roman Shpount <[email-masked]>
Date: Mon, 14 Nov 2011 20:02:20 -0500

On Mon, Nov 14, 2011 at 7:42 PM, Matthew Kaufman
<[email-masked]>wrote:

> Do you want *your* browser to be able to switch to plain RTP for the call
> you're making from a place with an unsecured wi-fi network (as essentially
> all are at this point, given the ease of cracking the typical schemes used
> for wireless security these days) ?
>

I guess you are missing the point on two accounts:

First of call, in most of the cases I (as well as possibly most of the
people) do not care. If I am sitting on the public WiFi in a coffee shop, I
do not care, because there are hundreds of people around who already hear
what I am saying. Almost all traditional phone conversations provided no
privacy (just ask your friendly phone technician which a handset in the
basement), and most of people did not care. Cell phones are not as private
as you would think (I know of examples when entire countries turned the
encryption off for a few months) and users did not care. Encryption is
good, but not as important as you are making it to be.

Second, it is an application developers decision if he wants to provide
secure communications. If he does not intend to (all conversations are
recorded and posted on the web as a voice blog for example), there is no
point of forcing this encryption. No matter what we do on the browser side,
the app will never be secure, if it is not intended to be so. In this case
all this encryption is a wasted effort. It is not a web browser or a user
decision if communications with a particular app should be secure. User
should be able to see that the certain application takes no effort in
securing the communications and decide if they would use this application
based on this. The simplest and probably best understood model by web users
is, if an application is delivered over HTTPS from a known provider, it
should be secure. If it is delivered over HTTP, it provides no guarantees
over its security and should be used this at your own risk.
_____________
Roman Shpount

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 15 Nov 2011 09:03:41 +0800

On 11/14/11 6:37 PM, Wolfgang Beck wrote:
> If we do connect POTS lines
> to the browser, we have to talk about fax as well.

I fail to follow the leap you have made here. If we're going to make a 
leap, wouldn't exposing ringing voltage to the user's keyboard be of 
more value?

Matthew Kaufman

---

From: Wolfgang Beck <[email-masked]>
Date: Tue, 15 Nov 2011 09:10:26 +0800

On Tue, Nov 15, 2011 at 9:03 AM, Matthew Kaufman
<[email-masked]> wrote:
> I fail to follow the leap you have made here. If we're going to make a leap,
> wouldn't exposing ringing voltage to the user's keyboard be of more value?
I was talking about a hopefully hypothetical system which exposes an
analogue phone via a POTS port to a browser as sound device.
Better not give people ideas..

Wolfgang Beck

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 15 Nov 2011 09:14:01 +0800

On 11/15/11 9:02 AM, Roman Shpount wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Do you want *your* browser to be able to switch to plain RTP for
>     the call you're making from a place with an unsecured wi-fi
>     network (as essentially all are at this point, given the ease of
>     cracking the typical schemes used for wireless security these days) ?
>
>     I don't. Even though I do agree that there might be external
>     reasons why service providers might want the browser to have that
>     ability.
>
>

Perhaps. They're unrelated, so I'll answer separately.
> people) do not care. If I am sitting on the public WiFi in a coffee 
> shop, I do not care, because there are hundreds of people around who 
> already hear what I am saying.
But they're not able to record what you're saying from a close-up 
microphone. Nor can they record you from a car sitting outside the 
coffee shop. Nor can they record what the far end is saying. Nor can 
they replace what you're saying with alternative audio.

All of which *are* possible when plain RTP is sent over public WiFi.

> Almost all traditional phone conversations provided no privacy (just 
> ask your friendly phone technician which a handset in the basement), 
> and most of people did not care.

Just because phone tapping is relatively easy doesn't mean we shouldn't 
be improving the state of the art here.

> Cell phones are not as private as you would think (I know of examples 
> when entire countries turned the encryption off for a few months) and 
> users did not care. Encryption is good, but not as important as you 
> are making it to be.

To you.

>
> Second, it is an application developers decision if he wants to 
> provide secure communications. If he does not intend to (all 
> conversations are recorded and posted on the web as a voice blog for 
> example), there is no point of forcing this encryption.

Maybe. Even if the conversations are recorded and posted, there might be 
cases where you don't want alternative audio being substituted. (For 
instance.)

> No matter what we do on the browser side, the app will never be 
> secure, if it is not intended to be so. In this case all this 
> encryption is a wasted effort. It is not a web browser or a user 
> decision if communications with a particular app should be secure. 
> User should be able to see that the certain application takes no 
> effort in securing the communications and decide if they would use 
> this application based on this. The simplest and probably best 
> understood model by web users is, if an application is delivered over 
> HTTPS from a known provider, it should be secure. If it is delivered 
> over HTTP, it provides no guarantees over its security and should be 
> used this at your own risk.

You really don't want to ever provide access to your camera and 
microphone to an application delivered over HTTP, because once it is 
delivered over HTTP you don't know that the application hasn't been 
replaced with something that sends your camera and microphone to 
somewhere other than what you had intended. And you *definitely* don't 
want to press the "remember my choice" checkbox for applications 
delivered over HTTP.

In short, I would strongly suggest that applications delivered over HTTP 
*never* be able to access your camera and microphone. (Noting that in 
most cultures, knowing what a user is looking at or typing isn't nearly 
as sensitive as listening in or seeing what the user happens to be 
wearing (or not wearing)).

Matthew Kaufman

---

From: Tim Panton <[email-masked]>
Date: Tue, 15 Nov 2011 08:31:55 +0000

> in Those Proprietary Plugins That Must Not Be Named, the data channel of a stream can be fully reliable or partially reliable. the timing semantics for a time-synchronized data message is that it w…

Not all proprietary plugins are Flash ;-) - We have a Java  applet that implements IAX - which ends up 
with similar properties - you can send and receive data (in a few formats although mostly we ended up
putting JSON in text) - the data is reliable, timestamped with the media time,  sequenced datagram (not a stream). Most usages ignore the media timestamp and just process it 'immediately' but on occasion the timestamp is useful.

Tim.

---

From: Tim Panton <[email-masked]>
Date: Tue, 15 Nov 2011 08:39:07 +0000

> Better not give people ideas..

Ohh, can I have the Hayes AT command set and pulse dialling too ? 

I've a 60s rotary phone I'd like to put into service.

Tim.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 15 Nov 2011 10:09:56 +0100

> I've a 60s rotary phone I'd like to put into service.

I need an interface to connect my old Cinexin into the browser:

  http://macrunraff.files.wordpress.com/2010/09/cinexin.jpg

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 15 Nov 2011 10:16:56 +0100

2011/11/15 Matthew Kaufman <[email-masked]>:
> Why *wouldn't* you want the JavaScript client code to participate in this
> decision?

It could, of course. Maybe a callback is executed for each forking
media session. If such callback returns "true" then the new session is
handled, otherwise it's ignored.

Another option would be set a "parameter" to allow media forking or
not prior to the call.

Or both options.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 15 Nov 2011 17:55:53 +0800

On 11/15/2011 08:52 AM, Matthew Kaufman wrote:
>> asynchronous Javascript function call, which is not synchonized to 
>> the media. Do we assume that the function call happens 'at about the 
>> right time' and take that as the current timestamp to use?
>
> "timed text track" and *not* a WebRTC-specific behavior of the side 
> data channel we've been talking about.
>
> can be displayed in-sync with the audio that I would love to run 
> inside a browser without <that plugin>.
audio/t140?

---

From: Tim Panton <[email-masked]>
Date: Tue, 15 Nov 2011 12:35:02 +0000

> what would the codec object represent?

The publicly useful state of a current codec instance. 

Properties like - bitrate, error - rate, width, height, quality
complexity, sample-rate, quantity available (possible hardware limits...), 
name, SDP stanza (perhaps), current status (initialized etc) 

Property change notifiers (if the far end changes what it is sending we get a notification here).

Setters for such properties as make sense to set (some might be valid only pre-initialization)

codec specific events  (silence detection, tone detect, typing detect , 
whiteout, dtmf perhaps, movement detection)

And the really controversial one:  an api to allow manipulation of the encoded and
decoded datastreams by inserting filters into the pipeline before or after the codec.
- (Like DMR's streams pre unix SystemV)

> How would a codec object relate to the MediaStreamTrack object?

I don't know - let me look at the MediaStreamTrack again and get back to you.

> (this is an api discussion, so probably belongs on the W3C list)

Lets keep it here for now and see if anything solid comes of it.

---

From: Justin Uberti <[email-masked]>
Date: Tue, 15 Nov 2011 08:59:10 -0500

On Tue, Nov 15, 2011 at 7:35 AM, Tim Panton <[email-masked]> wrote:

> systems,

Please, at least move this discussion to a new thread.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 16 Nov 2011 00:47:24 +0800

Inaki Baz said

"75 percent of the traffic on the list is about SIP.... where is the innovation?"

[BA] Maybe if we stopped talking about SIP, we'd have time to talk about something else.  

Take a deep breath. I. will. not. talk. about. SIP. today. 

Thank you!

Bernard "International no SIP day on RTCWEB list" Aboba

---

From: Victor Pascual Avila <[email-masked]>
Date: Tue, 15 Nov 2011 17:49:57 +0100

> Bernard "International no SIP day on RTCWEB list" Aboba

200 OK

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 15 Nov 2011 23:05:11 +0100

2011/11/10 Eric Rescorla <[email-masked]>:
> we have a whole array of protocols which really should

+1

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 28 Nov 2011 13:23:00 -0700

> telepresence. May be multiple variant of TP exists </partha>

right - each screen is 1 video stream in RTP so I think we are saying the same numbers - makes sense

> telepresence recording & communication session and it was accepted in

Might want to go poke on that requirement a bit and see what you get