Subject: [MMUSIC] Review of draft-ietf-mmusic-trickle-ice-sip-02

From: Simon Perreault <[email-masked]>
Date: Thu, 10 Sep 2015 17:24:48 -0400

WG,

In Prague I volunteered to review this draft. Here's my review.

In general the document is close to being done, but there are a few
minor things that require a new revision before WGLC.

Major
=====

(nothing)

Minor
=====

- There are quite a few open issues and notes that need to be closed:

6. Considerations for RTP and RTCP multiplexing

   [OPEN ISSUE: These considerations are of general relevance
   and might be better suited for draft-ietf-mmusic-trickle-ice.]

7.  Considerations for Media Multiplexing

   [OPEN ISSUE: These considerations are of general relevance
   and might be better suited for draft-ietf-mmusic-trickle-ice.]

9.8.  Rate of INFO Requests

   [OPEN ISSUE: What rate will give a good trade-off? 100ms, 200ms?]

9.6.  Info Message Body Parts

   [NOTE: end-of-candidates-att currently lacks a formal definition in
   [I-D.ietf-mmusic-trickle-ice]]

- "Section 4.1. Establishing the dialog" says: "The SIP dialog at both
sides MUST be at least in the early state."

What does "at least" mean in this context? Do states have numerical
value? I sort of get what the intent is, but it could be stated more
precisely.

- On page 11 I suggest rewording for clarity:

OLD:
   This
   INFO message can repeat the candidates that were already provided in
   the Offer (as would be the case when Half Trickle is performed or
   when new candidates have not been learned since then) or they can
   also deliver new new candidates (if available).
NEW:
   This
   INFO message MAY repeat the candidates that were already provided in
   the Offer (as would be the case when Half Trickle is performed or
   when new candidates have not been learned since then) and/or they MAY
   deliver new candidates (if available).

- Sections 4.1.2 and 4.1.3 contain this:

   When sending the Answer in the 200 OK response, the Answerers MUST
   repeat exactly the same Answer that was previously sent in the
   unreliable provisional response in order to fulfill the corresponding
   requirements in [RFC3264].

Doesn't that also apply to 4.1.1 and 4.1.4? If so, wouldn't it make
sense to factor it out so that it applies in every case?

- On page 18, the example's content-type should be application/sdpfrag.

- On page 26, please make the lines fit the RFC format line width.

Nits
====

Page 6: s/In order for to benefit/In order to benefit/
Page 10: s/provisioanl/provisional/
Page 12: s/Answerers/Answerer/
Page 12: s/less candidates/fewer candidates/
Page 12: s/SIPfrag/SDPfrag/
Page 12: s/M UST/MUST/
Page 13: s/less candidates/fewer candidates/
Page 17: s/local candidates/host candidates/
Page 22: s/sdp-frag/sdpfrag/

---

From: Thomas Stach <[email-masked]>
Date: Fri, 11 Sep 2015 09:01:36 +0200

Simon,

thanks for the review.
More inline.

>     and might be better suited for draft-ietf-mmusic-trickle-ice
>
My proposal for these is to keep the text in this document.
draft-mmusic-trickle-ice can still include (or repeat) corresponding 
text for other applications
of Trickle ICE outside of SIP.
>     [OPEN ISSUE: What rate will give a good trade-off? 100ms, 200ms?]
This was discussed in IETF-93. We will not recommend an explicit value.
>     [I-D.ietf-mmusic-trickle-ice]]
Something to be resolved in draft-mmusic-trickle-ice. I'll keep this 
note until it is done.
> value?
This refers to https://tools.ietf.org/html/rfc3261#section-12.
I could reword to "The dialog at both sides MUST be in early or 
confirmed state"
> I sort of get what the intent is, but it could be stated more
> precisely.
>
>
OK
> sense to factor it out so that it applies in every case?
In 4.1.1 and 4.1.4 the answer is sent only once.
In case of 4.1.1 this is a reliable provisional response, in 4.1.4 it is 
either the PRACK (offer in reliable provisional response) or in the ACK 
(offer in 200OK).
RFC6337 deals with unnecessary repetitions, but I don't think we need to 
reference that one here.
> - On page 18, the example's content-type should be application/sdpfrag.
Will be addressed
> - On page 26, please make the lines fit the RFC format line width.
OK
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Simon Perreault <[email-masked]>
Date: Fri, 11 Sep 2015 09:28:16 -0400

> of Trickle ICE outside of SIP.

Works for me.

> This was discussed in IETF-93. We will not recommend an explicit value.

WFM.

> Something to be resolved in draft-mmusic-trickle-ice. I'll keep this

Good.

> I could reword to "The dialog at both sides MUST be in early or

WFM.

> RFC6337 deals with unnecessary repetitions, but I don't think we need to

Ah, right, thanks. No change needed.

Simon