Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP
From: Roman Shpount <[email-masked]>
To: Cullen Jennings <[email-masked]>
Cc: lemming Andreasen <[email-masked]>, RTCWeb IETF <[email-masked]>, mmusic WG <[email-masked]>
Date: Wed, 28 Nov 2018 11:57:13 -0500
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>

On Wed, Nov 28, 2018 at 11:38 AM Cullen Jennings <[email-masked]> wrote:

> On Nov 27, 2018, at 4:46 PM, Roman Shpount <[email-masked]> wrote:
>
>  I suggest to update JSEP section 5.1.2 to match the rest of the
> documents to say that "UDP/TLS/RTP/SAVPF" proto MUST be used during ICE
> restart. When ICE restart is not in progress, "UDP/TLS/RTP/SAVPF" proto
> MUST be used if default (only) candidate is a UDP candidate and
> "TCP/TLS/RTP/SAVPF" proto MUST be used if default (only) candidate is TCP
> candidate.
>
>
> I don’t see any real befits to implementations to this change and I don’t
> think the rtcweb consensus was around the currently solution. Do you see
> some advantage to implementations to this?
>

This is what every other document related to ICE, including JSEP section
5.2.2 currently specifies. It was also consensus in MMUSIC. I think RTCWEB
need a really good reason why it needs to be different.

Also, if we are not going to do this, then every ICE implementation for
RTCWEB would be different from every other ICE implementation. For
instance, without this change, when ICE TCP candidate is selected, WebRTC
compliant implementation MUST use UDP/TLS/RTP/SAVPF in subsequent
offer/answer exchanges, but it MUST use TCP/TLS/RTP/SAVPF in the same case
when communicating with VoIP phone. It would be very hard to change this
behavior in ice-sip-sdp, since it will make it incompatible with RFC5245m
so this difference is likely to be permanent.

Regards,
_____________
Roman Shpount