Re: [rtcweb] Proposal to break the ICE impasse

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

On Tue, 29 Jan 2019 at 02:10, Ted Hardie <[e-mail]> wrote:

> That consensus was limited to JSEP; other related uses of SIP/SDP do not treat it as meaningless.
>
> The additional complexity added to a system is, of course, always a concern.  But  I interpret your statement "If it's necessary, then I'm willing to live with it." as agreeing that this solution will work if the additional domain of interoperability which results is not empty.

The summary is basically that it adds extra complexity to WebRTC
without absolutely any advantage or added feature. Anyway:

> Implementations MUST indicate this profile for each media m= line they
produce in an offer unless the media section contains only TCP candidates;
if all candidates use TCP as a transport, implementations MUST indicate
"TCP/DTLS/RTP/SAVPF," to allow for compatibility with non-WebRTC
implementations

Some concerns:

1) Browser and WebRTC "clients" will always offer UDP candidates, so
the above is not likely to happen.

2) If it happens (there are just TCP candidates) this is probably
because the server mandates TCP, so the "service monitoring system"
already knows that.

3) The browser offers UDP and TCP candidates so will place
"UDP/TLS/RTP/SAVPF" in the transport. Then the server replies with
just TCP candidates. I assume that the server would also use
"UDP/TLS/RTP/SAVPF" in the answer (because it must match the transport
value in the offer) but, do we expect that the browser will "send a
re-offer with TCP/DTLS/RTP/SAVPF" to conform to this spec? That won't
happen. So how is this useful at all for the service monitoring
system?


Instead of all this folklore, couldn't the "phone" just send a
multi-purpose OPTIONS somewhere once it knows the selected ICE tuple
and we are done? That can be easily implemented in flexible SIP and
WebRTC stacks.

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