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

[Roman Shpount <[e-mail]>]

On Wed, Nov 28, 2018 at 1:59 PM Justin Uberti <[e-mail]> wrote:

> Regarding the current conflict between 5.1.2 and 5.2.2, this is discussed
> in https://github.com/rtcweb-wg/jsep/issues/854, and the editor team
> concluded that 5.2.2 should be brought in line with 5.1.2 by removing the
> need to match the protocol field. I think this change is important to make
> to avoid future confusion.
>
> This conclusion was a result of reviewing the prior discussion in
> https://mailarchive.ietf.org/arch/msg/mmusic/gR-dYY1GzN3fIA_XlHiX-bB6nLM,
> where this topic was previously litigated. That email thread concluded with
> the message in
> https://mailarchive.ietf.org/arch/msg/mmusic/p6AFDGqbNm57P6s1cN2ZOUUDj2U,
> where Roman seemed to be in agreement with the proposal.
>

The discussion you are referring to was about the initial ICE offer/answer
exchange. I agree that during offer/answer exchange which initiate ICE
restart, only UDP based protocols should be used in the m= line. For me,
this is what section 5.1.2 describes. When ice-sip-sdp and related
documents (sctp-sdp and fc4583bis) were written, this logic was slightly
"fine tuned" for offer/answer exchanges which do not initiate ICE restart.
For these exchanges, it was decided to use the protocol of the only ICE
candidate pair present. This was important for backwards compatibility with
RFC 5245, especially when signaling agent monitors values in c= and m=
lines and actually cares about the address and protocol used there.  This
is what JSEP section 5.2.2 is describing and what you want to change. I
agree this is not extremely important for JSEP use cases, but unlikely to
change in ice-sip-sdp, since it is important there. Because of this, we are
going to end up with two specifications, and ICE implementations, which are
slightly different for no reason. As an implementer, this is an extra
"flag" I need to set when instantiating my ICE library.

Second part of the problem for me are the values of address and port in the
c= and m= line when no candidates in session description match the protocol
in the m= line. I do not think it was discussed anywhere except during
trickle ICE, where it was specified to set c= to IN IP4 0.0.0.0 and m= line
port to 9 when no candidates are present. If this can be extended to the
case when ICE candidates are present but do not match the proto in the m=
line, I would be happy since this will prevent ICE mismatch with
ice-sip-sdp compliant implementations. If you do not want to update JSEP to
do this, it can be added in ice-sip-sdp. Just please do not put something
in JSEP which will force it to update c= and m= line with address and port
of mismatching candidate.

Regards,
_____________
Roman Shpount