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

[Iñaki Baz Castillo <[e-mail]>]

2011/11/13 Hadriel Kaplan <[e-mail]>:
>> 2011/11/13 Hadriel Kaplan <[e-mail]>:
>>> 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.
>
> 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]

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

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.




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




>> 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 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
<[e-mail]>