Re: [MMUSIC] Comments on draft-ietf-mmusic-ice-sip-sdp-16 - Part II

[Suhas Nandakumar <[e-mail]>]

Hello Christer

Many thanks for the review. I have attempted to answer your concerns here.
Please let me know if the proposals look good and I can work on them
during the next revision.

Thanks
Suhas

On Mon, Mar 5, 2018 at 10:18 AM, Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
> Some more comments/questions:
>
>
> Q0:
>
> Section 4.1.4 talks about performing connectivity checks. I don¹t think it
> should talk about role conflicts (or, the section should be renamed to
> ŒRole conflicts¹).
>
> Unless I¹ve missed something, the only SDP-specific thing about
> connectivity checks is how/if inactive/sendonly/recvonly/sendrecv impacts
> it. For keepalives the draft says it doesn¹t, but I can¹t find any text
> about connectivity checks in general.
>
>
[Suhas]. Connectivity checks are indeed Role specific isn't it and I am not
sure it has SDP counterpart either. For example, even for sendonly/recvonly
stream you still do connectivity checks for RTCP. This sections just
points to relevant sections in ICEBis to have a coherent flow of the
understanding.




>
> Q0.1:
>
> Section 4.2.4.1.1. talks about multiple nominated pair for a given
> component. Again, that only happens with aggressive nomination, and should
> be removed from this draft.
>
>
[Suhas] How about the following rewording
The agent MUST remember the nominated pair , called the previous selected
pair, prior to the restart. The agent will continue to send media using
this pair, as described in Section 7.1
<https://tools.ietf.org/id/draft-ietf-mmusic-ice-sip-sdp-16.html#sec-send_media>.
Once these destinations are noted, the agent MUST flush the valid and check
lists, and then recompute the check list and its states as described in
section 6.1.2 of

>
>
> Q1:
>
> Section 6 describes keepalives.
>
> I don¹t think the following sentence belongs to the section:
>
>    "An agent can determine that its peer supports ICE by the presence of
> a=candidate attributes for each
>    media session.²
>
> How agents determine support is described elsewhere.
>

[Suhas] Agree, we can remove that sentence and probably add it in 4.1.2.3
instead ?

>
>
> Q2:
>
> Section 7.1 and 7.2 is about media handling. The handling of mismatch
> between selected pair and default pair should be described elsewhere.
>
> What does the following mean?
>
>     "Furthermore, in very unusual cases, the default candidates in the
> updated offer/answer will not be a match.²
>
>
>
> Q3:
>
> Section 8 says:
>
> "Note that ICE is not intended for NAT traversal for SIP, which is assumed
> to be provided via another mechanism [RFC5626].²
>
>
> I suggest to say ³e.g., using the mechanism defined in [RFC5626].²
>

[Suhas] will do


>
>
> Q4:
>
> In section 8, doesn¹t the second paragraph (about forking) belong in
> Section 8.3?


[Suhas] Sure, will move


>
>
> Q5:
>
> In section 8.1, what does the following mean?
>
> "These checks can take time to complete, and as such, the selection of
> messages to use
>  with offers and answers can affect perceived user latency.²
>
>
> Are you referring to the SIP methods for carrying offers/answers?
>

[Suhas] Yes, that's correct. Do you think we should add clarification
saying "the selection of SIP messages to use" instead ?


>
>
> Q6:
>
> In section 8.2, why is the support of the option tags and feature tags
> SHOULD, instead of MUST?
>

[Suhas]. I am not sure of the original intent here. Marc, would love to
hear your inputs .


>
>
> Q7:
>
>
> In section 8.3, I think it should be described that, when forking occurs,
> ICE processing is done independently on each fork.
>
>
[Suhas] 2nd Para in Section 8 talks about exactly  this.
" ICE proceeds completely in parallel and independently for each answer,
treating the combination of its offer and each answer as an independent
offer/answer exchange"

I can move that para to this section 8.3 to bring in clarity


>
> Q8:
>
> In section 8.3, the text says:
>
> "Without ICE, when a call forks and
>    the caller receives multiple incoming media streams, it cannot
>    determine which media stream corresponds to which callee.
>
>    With ICE, this problem is resolved.  The connectivity checks which
>    occur prior to transmission of media carry username fragments, which
>    in turn are correlated to a specific callee."
>
>
> First, you need to describe HOW to determine which media stream
> corresponds to which callee. There are no username fragments etc in the
> media packets. Are you talking about comparing the source addresses of
> STUN connectivity checks and media packets, or?
>

[Suhas] The para talks about mapping fragments present in connectivity
checks to candidate pair on which media arrives. That's how callee
stream gets mapped.


>
> Second, while each peer will you have different username fragments, you
> need to describe whether the caller can use the same on each fork.
>
>
[Suhas].I am not sure how is that impacting this section.
The combination of caller + callee's user fragment is unique from the
Caller's perspective.


>
> Q9:
>
> Is there something SIP/SDP specific in section 10? If not, I think we can
> remove the section.
>
>
[Suhas] I agree . There isn't, do you suggest we remove it ?


>
> Q10:
>
> In sections 11 and 12, I think nowadays the contact for new attributes etc
> shall be IESG.
>
>
[Suhas] We will update as suggested


>
> Regards,
>
> Christer
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>