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

[Simon Perreault <[e-mail]>]

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/