Re: [rtcweb] Default proto transport in JSEP

[Roman Shpount <[e-mail]>]

On Mon, Nov 19, 2018 at 3:31 PM Iñaki Baz Castillo <[e-mail]> wrote:

> On Mon, 19 Nov 2018 at 21:21, Roman Shpount <[e-mail]> wrote:
> > ICE specifications (both RFC 5245 and ice-sip-sdp) are saying that these
> fields are not cosmetic. All I am asking is to put values in these fields
> that indicate that they are cosmetic instead of creating some rules on how
> these fields should change which would cause potential interop issues.
>
> I suggest:
>
> m=KIND 9 ICE [codec PTs]
>

If you are re-inventing the protocol, why would you build SDP or m= lines?
If you are using an existing protocol, why do you modify it in the way it
is not compatible with anything in existence?

I am suggesting always doing something like:

m=audio 9 UDP/TLS/RTP/SAVPF [codec PTs]
c=IN IP4 0.0.0.0

Do you see any issues with this except being aesthetically offended?

> BTW, there are plenty of VoIP phones which use ICE and support Opus (or
> G.711). They will also produce ICE mismatch since they implement RFC 5245.
> So, these end points are WebRTC compatible except for this specific issue.
>
> If those phones already implement ICE (and let's assume also
> DTLS-SRTP), how will a wrong or "invalid" c= or m= content affect
> them? Browsers won't complain no matter what the SDP re-offer contains
> in those lines, so the phone can put whatever it wishes. And the phone
> should not read them in received SDP re-offers, so I don't fully
> understand what the problem is.
>

Please read
https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.2.5
Some people for some reason insist on following specifications. If you
propose to do two opposite things, random things start being implemented.

Regards,
_____________
Roman Shpount