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

[Benjamin Kaduk <[e-mail]>]

On Tue, Aug 06, 2019 at 01:51:23PM -0400, Roman Shpount wrote:
> 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.

Ah, I had missed that subtlety.  It sounds like this would be useful in a
"changes from RFC 5245" section, except that per Alissa's position, we are
probably not obsoleting RFC 5245 anymore in this document.  But probably we
can still have a similar section.

> 
> > (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.

The correction is appreciated :)

Thanks,

Ben

> 
> > 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