Re: [rtcweb] interworking with non-WEBRTC endpoints SDES-SRTP + DTLS-SRTP [was RE: Use Case draft]

["Fabio Pietrosanti (naif)" <[e-mail]>]

Well,

maybe it's just the "signaling provider" that will tell to the browser
what to use:

- simpler interoperable SDES/SRTP (saying to the user "send SRTP here
IP:Port with that Key)
- stronger non-interoperable DTLS-SRTP (saying to the user "go
peer-to-peer")

For example if the signaling provider know that it's providing:
a) A call to a center call
b) Call trough PSTN gateway (web call to PSTN)
c) Voicemail access
d) Financial call (stock brokerage)
e) Enterprise call (that would just need to proxy all calls)

then the signaling provider will notice to the user's WebRTC stack
SDES/SRTP in a *very simple* way without ICE/DTLS-SRTP and all that
protocol complexity.

Instead if that specific VoIP uses does not require a VoIP server to
provide value added services (transcoding, conferencing, bridging to
other telephony networks, recording, whatever) it would just goes as
DTLS-SRTP.

Some previous link on the topic:

* On DTLS-SRTP trust model (and consideration for SDES-SRTP)
http://www.ietf.org/mail-archive/web/rtcweb/current/msg04007.html

* End-to-end encryption vs end-to-end authentication (DTLS-SRTP / SDES-SRTP)
http://www.ietf.org/mail-archive/web/rtcweb/current/msg04032.html

*  DTLS-SRTP with end-to-end security: Short Authentication String
http://www.ietf.org/mail-archive/web/rtcweb/current/msg04123.html

Fabio

On 5/3/12 7:23 AM, Ravindran, Parthasarathi wrote:
> Fabio,
> 
> Could you please explain how to differentiate through protocol means that the peer is site (gateway) or endpoint (webbrowser).
> 
> Thanks
> Partha