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

[Ted Hardie <[e-mail]>]

Hi Roman,

The current pull request resolves the 5.1.2 vs. 5.2.2 ambiguity in line
with the discussion here:

https://github.com/rtcweb-wg/jsep/issues/394

and then here:

https://mailarchive.ietf.org/arch/msg/mmusic/gR-dYY1GzN3fIA_XlHiX-bB6nLM

I understand from your comments on
https://github.com/rtcweb-wg/jsep/issues/854 that you disagreed with that
being the final consensus, and it has since been discussed on the list as
Justin suggested in that issue.

At the moment I continue to see only you objecting to the combination of
the current pull and an update to ice-sip-sdp.   Since ice-sip-sdp is in
MMUSIC, not RTCWEB, it's not up to the RTCWEB chairs to call the final
consensus here, but I believe my previous statement on the preference for
RTCWEB remains true.

regards,

Ted



On Wed, Nov 28, 2018 at 10:42 AM Roman Shpount <[e-mail]> wrote:

>
> 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
> <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
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>