Re: [MMUSIC] Benjamin Kaduk's Discuss on draft-ietf-mmusic-ice-sip-sdp-37: (with DISCUSS and COMMENT)

[Roman Shpount <[e-mail]>]

Hi Benjamin,

Thank You for the review!

I agree with most of what Chirster said with some clarifications tha I have
provided inline.

On Tue, Aug 6, 2019 at 8:42 AM Christer Holmberg <
[e-mail]> wrote:

> > Do we have anywhere a definition of what it means to "indicate ICE
> support in an SDP offer/answer"?
> > (As distinct from ice2 support.)  We refer to the concept in several
> places but there are many protocol
> > fields that might be interpreted as such; is any one of them sufficient?
>
> I don't there is a definition. It basically means when the offer or answer
> contains ICE-related attributes.
>
> I guess we could add some text about that.
>

We can add some language in section 3.2.5 "Verifying ICE support". We will
need to add that ice-ufrag and ice-pwd must be specified for the m= line.
If these two attributes are specified  and the rest of the conditions
specified in section 3.2.5 are satisfied, ICE is supported and procedures
specified in this document are used.


> Section 3.2.2
>
> > Aren't "rtcp attribute SHOULD be included" and "rtcp attribute MAY be
> omitted" just duplicating existing normative requirements
> > from previous specifications (which thus would not need new normative
> language here)?
>
> Correct. The SHOULD and MAY shall not be normative. The MUST will remain,
> though.
>

Part of the problem is that RFC 5245 section 4.3 (
https://tools.ietf.org/html/rfc5245#section-4.3) specified that a=rtcp
attribute MUST be included. This specification relaxes this requirement and
states that a=rtcp attribute SHOULD only be included if separate port is
used for RTCP and RTCP port is not RTP port plus one. This language reverts
RFC 5245 language to original requirements from RFC3605.


> (Unfortunately, for backward compatibility, we have to deal with some
> legacy offer/answer restrictions, including those related to the m= line
> values. If we would know that every device (including intermediaries)
> support ICE we wouldn't need the m= line for anything)
>
> I think Adam earlier addressed Éric's comment on having IPv6 examples.
> However, if including IPv6 examples would make the spec more easy to
> understand then I think we should include them.
>

We can include IPv6 host candidates in examples. This would reflect the
real use cases.


> Section 3.4.1.2.2
>
> >   line associated with that data stream MUST match the data associated
> >   with the nominated pair for that data stream.  In addition, the
> >   offerer only includes SDP candidates representing the local
> >   candidates of the nominated candidate pair.  The offerer MUST NOT
> >   include any other SDP candidate attributes in the subsequent offer.
> >
> > Does this mean that exactly one a=candidate line must appear in the
> corresponding m= section?
>
> Correct. Do you think that needs to be more clear?
>

Correction, one candidate per component must appear in the corresponding m=
section. If RTCP is used, two candidates will be present.


> Section 6.1.1
>
> >   described in [RFC3262].  Such retransmissions MUST cease on receipt
> >   of a STUN Binding request with transport address matching candidate
> >   address for one of the data streams signaled in that SDP or on
> >   transmission of the answer in a 2xx response.  If no Binding request
> >
> > nit: I think "candidate address" needs an article.
>
> I guess "transport address" also needs one?
>
> Something like:
>
> "with a transport address matching the candidate address for..."
>
> >   the session terminated.  For the ICE lite peers, the agent MUST cease
> >   retransmitting the 18x after sending it four times since there will
> >   be no Binding request sent and the number four is arbitrarily chosen
> >   to limit the number of 18x retransmits (poor man's version of
> >   [RFC3262] basically).  (ICE will actually work even if the peer never
> >
> > nit: the tone of the parenthetical is rather distinct from conventional
> RFC style.
>
> Unless the other authors want to keep/modify it, I suggest to remove all
> text after "...limit the number of 18x retransmits.
>
> The relation to RFC 3262 is already described earlier in the section.
>

Agreed as one of the authors..

Best Regards,
_____________
Roman Shpount