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

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Mar 2018 10:18:41 +0000

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.

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.

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.

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].²

Q4:

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

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?

Q6:

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

Q7:

In section 8.3, I think it should be described that, when forking occurs,
ICE processing is done independently on each fork.

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?

Second, while each peer will you have different username fragments, you
need to describe whether the caller can use the same on each fork.

Q9:

Is there something SIP/SDP specific in section 10? If not, I think we can
remove the section.

Q10:

In sections 11 and 12, I think nowadays the contact for new attributes etc
shall be IESG.

Regards,

Christer

---

From: Suhas Nandakumar <[email-masked]>
Date: Sun, 18 Mar 2018 17:52:30 +0000

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

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

> 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

> How agents determine support is described elsewhere.

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

> I suggest to say ³e.g., using the mechanism defined in [RFC5626].²

[Suhas] will do

> In section 8, doesn¹t the second paragraph (about forking) belong in

[Suhas] Sure, will move

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

> In section 8.2, why is the support of the option tags and feature tags

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

> 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

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

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

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

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

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