Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP?

["Makaraju, Maridi Raju (Raju)" <[e-mail]>]

> > [Raju1] You meant “you could still do that” using existing procedures?
> > Currently I don’t think Chrome updates c/m= lines ip/port to match with
> > final selected candidate.
> 
> Of course not, and that is why "you could still do that" (in case we
> get some PC event firing when the selected ICE candidate is paired, so
> *you* can inspect it at JS level and mangle your SDP).
[Raju] As I mentioned earlier, how about when TCP and UDP port #s are same? Take a look at the following example. In this case how do you know the exact Layer 4 transport used?

m=audio 58612 RTP/SAVPF 0 100
a=candidate:3275585311 1 udp 2122260223 135.252.136.43 58612 typ host generation 0
a=candidate:2378075119 1 tcp 1518280447 135.252.136.43 58612 typ host generation 0 

>And yes, this "breaks RFC 5764 and 5245". But what it breaks is
>useless and legacy and makes no sense in the context of WebRTC. So no
>problem.
[Raju] Why intentionally break it and add exceptions?!!
If we go in that direction and set wrong precedence to break RFC rules, then why not do any or all of the following to have a parallel webrtc universe?
- Just use "RTP" instead of "RTP/SAVPF" and assume DTLS-SRTP always.
- For data channel, just use "SCTP" instead of "SCTP/DTLS" and assume "DTLS" always.
We don't want to do that because webrtc respects and takes advantage of existing IETF RFCs.
IHMO, cherry picking is not a good idea... especially here where we don't have a strong case for it. I don't think FF to Chrome interop is a strong reason and I already suggested a way to have backward compatibility. IMHO, FF and Chrome should have used "UDP/TLS/RTP/SAVPF" for DTLS-SRTP from day 1; then we wouldn’t be having this discussion. 
I don't agree with the comment that "it's legacy"; it may not be prefect but since webrtc decided to adapt IETF STUN/ICE/SDP RFCs we should follow them with as few exceptions (zero should be the goal) as possible.


>So honestly I don't think that the W3C should design an API (or make
>it more complex) that makes happy old and legacy SDP procedures and
>requirements.
[Raju] As I mentioned before, we are not talking about a new API or making it more complex here. Existing API oniceconnectionstatechange () is sufficient to indicate the application about ICE completion. The extra stuff I am talking about is not API related, rather making SDP consistent with the selected candidate in an unambiguous way. 

BR
Raju