Re: [rtcweb] draft-kaplan-rtcweb-sip-interworking-requirements-00

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

2011/10/25 Hadriel Kaplan <[e-mail]>:
> I've submitted a draft listing some use-cases and resulting requirements for interworking from RTCWeb (or "WebRTC" as the case may be), to deployed SIP domains/devices.

I think this draft is useful, but IMHO this WG is becoming too much
oriented to "interoperability with SIP", even worse, "interoperability
with *already* existing SIP domains" (those that don't implement
security at all given the fact that most of the SIP deployments run in
private or trusted networks).

I expect that 99% of websites interested in offering RTCweb
capabilities won't be interested (or won't need) interoperability with
a SIP network neither inter-federation with other RTCweb "domains".
IMHO RTCweb should focus on making easy the RTCweb adoption by those
99% of websites. Interoperability with SIP is important, but IMHO it
should not be the main purpose of RTCweb.

Having said that, more participation of Web folks in this WG would be
nice. Probably they cannot help in technical RTC subjects by they can
give us a real vision of what is needed in the current Web model (just
my opinion).



> The draft also discusses the functions which may be required in an interworking device, should some of the requirements not be met.

Let me a question about section 4.2.2:

----------------------------
4.2.2     SRTP Termination    [...]   It should be noted that if SRTP
is required to be used for every    call by RTCWeb but the [SDES] key
exchange model cannot be used on    the RTCWeb side, then the
Interworking Function likely has to    terminate SRTP from RTCWeb even
if the SIP-domain supports SRTP,    because [SDES] is the most
commonly used form of key exchange in SIP
today.------------------------------

I was not aware of such limitation. Could you please point me to some
draft or mail thread in which that limitation (SDES key exchange model
cannot be used on the RTCWeb side) is explained?

Thanks a lot.


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