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

[Roman Shpount <[e-mail]>]

Hi Harald,

On Wed, Nov 21, 2018 at 7:59 AM Harald Alvestrand <[e-mail]>
wrote:

> Given the maturity of the documents (ice-sip-sdp: "WG Consensus: Waiting
> for Write-Up" since December 2017; JSEP: "RFC Ed Queue" since March 2018),
> it seems most logical to change draft-ietf-ice-sip-sdp to allow what JSEP
> has specified.
>
> The failure of the ICE WG to detect the incompatibility with JSEP is sad,
> but fixable.
>

First of all, this is an mmusic issue, not ICE

Second, we are discussing a new proposed change in JSEP.

Current draft version 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.


This change was made to be compatible with
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.


So, the draft in RFC Ed Queue is compatible with ice-sip-sdp, but
inconsistent. The new change will makes it consistent but incompatible with
ice-sip-sdp.

Second, the new change contradicts RFC5245 not just ice-sip-sdp. When
ice-sip-sdp was created it was intended to be backwards compatible with
RFC5245 and proposed change will break it.

Finally, this specific issue was discussed to death in mmusic group.
Consensus was reached and reflected in ice-sip-sdp, sctp-sdp (In
MissingRef), rfc4583bis (Submitted to IESG for Publication). So, you can
potentially overwrite ice-sip-sdp behavior in JSEP, but it would be hard to
update ice-sip-sdp without affecting the other mentioned documents.

In my opinion, the difference is largely aesthetic, not practical, so I'd
> go with "first approved document gets to specify".
>

The change is not simply aesthetic. The result of this change is that you
need a special flag for ICE implementation to be compatible with JSEP (put
UDP protocol in m= line when ICE TCP candidate is used in subsequent
offers) vs being compatible with RFC 5245 (use TCP protocol when ICE TCP
candidate is used in subsequent offers). So, if you are using the same
infrastructure when dealing with multiple call sources (for instance we do
this for SIP calls from VoiP phones and SIP-over-websockets calls from web
browsers), you will need to maintain a special "profile" flag to treat
calls from browsers differently.

So, I think JSEP section 5.1.2 should be updated instead 5.2.2 to keep JSEP
compatible with RFC 5245, ice-sip-sdp and the rest of the documents.

Regards,
_____________
Roman Shpount