Re: [MMUSIC] [rtcweb] Default proto transport in JSEP

[Roman Shpount <[e-mail]>]

Hi Adam,

On Wed, Nov 28, 2018 at 1:22 PM Adam Roach <[e-mail]> wrote:

>
> On 11/28/18 10:57 AM, Roman Shpount wrote:
>
> On Wed, Nov 28, 2018 at 11:38 AM Cullen Jennings <[e-mail]> wrote:
>
>> On Nov 27, 2018, at 4:46 PM, Roman Shpount <[e-mail]> 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.
>
> It would probably help clarify things if you quoted the parts of the
> document that you think are in conflict. I can't find any explicit <proto>
> field handling in 5.2.2.
>
 I have mentioned this already in the previous message, but I guess this
got lost in the traffic.

JSEP-25 in section 5.2.2 says (
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.2.2):

Each "m=" and c=" line MUST be filled in with the port, *protocol*, and
address of the default candidate for the m= section, as described in
[I-D.ietf-mmusic-ice-sip-sdp], Section 3.2.1.2.


At the same time section 5.1.2 says (
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.1.2):

For media m= sections, JSEP implementations MUST support the
"UDP/TLS/RTP/SAVPF" profile specified in [RFC5764], and MUST indicate this
profile for each media m= line they produce in an offer. For data m=
sections, implementations MUST support the "UDP/DTLS/SCTP" profile and MUST
indicate this profile for each data m= line they produce in an offer.

So, section 5.2.2 says m= line should be filled with currently used
protocol, which means "TCP/TLS/RTP/SAVPF" or "TCP/DTLS/SCTP" if default
candidate is TCP based, but section 5.1.2 says it must be "UDP/TLS/RTP/SAVPF"
or "UDP/DTLS/SCTP", even if default candidate is TCP based. I thought that
section 5.2.2, since it is more specific, overwrites 5.1.2, which I assumed
only applies to ICE restart. Authors disagree and want to update the
document.

> In terms of changing technical aspects of JSEP: the only reason the
> document is out of the RFC Editor's queue right now is to address issues
> arising from rationalizing the reference to RFC 8445 within Cluster 238.
> This is not an opportunity to re-litigate previously settled consensus
> decisions. Technical issues such as the one at hand should have been raised
> during WG development, WG last call, or -- in extremis, since you're a
> regular RTCWEB participant -- during IETF last call. It's up to the chairs
> what to allow, but I wouldn't expect anything other than catastrophic flaws
> to be open for change at this time.
>
I am not the one who opened this can of worms. I am fine if the current
draft version is not changed. This is why I did not comment during the WG
last call. Draft authors are introducing the new change in
https://github.com/rtcweb-wg/jsep/pull/857, which makes JSEP incompatible
with ice-sip-sdp. I oppose this change. If the group considers that a
change to clarify things is necessary, I would suggest that section 5.1.2
should be changed instead to that it only applies during ICE restart, so
that JSEP is compatible with ice-sip-sdp.

Regards,
______________
Roman Shpount