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

[Christer Holmberg <[e-mail]>]

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