Subject: [MMUSIC] Some more questions and comments on draft-ietf-mmusic-ice-08

From: Philip Matthews <[email-masked]>
Date: Fri, 21 Apr 2006 10:19:13 -0400

Jonathan:

A few questions about the specification:

1)  Can a single offer contain candidates for the same media stream  
that use different transport protocols??
      The spec seems to handle this case, but I could not find a  
statement that this is allowed.

2)  Must all components of a candidate use the same transport protocol?

3) Must the components of a candidate appear together in increasing  
order in the SDP, or can they appear
      in any order and intermixed with candidates from other components?

And here are some comments. These are mostly editorial in nature.

General comments:
-  Shouldn't this specification reference draft-ietf-mmusic-sdp-new  
instead of RFC 2327?
    (See, for example, the references in section 12)

-  RFC 3264 (offer/answer model) and draft-ietf-mmusic-sdp-new state  
that the address and port
    in the m/c line is the one used to receive media on. However,  
when using ICE in the presence of NAT,
    this must also be the address and port from which the media is  
_sent_.
    I think it would be helpful to state this explicitly somewhere  
near the  beginning of the specification.

Section 2:
-  In the definition of a Relayed Transport Address, it might be  
helpful to readers to mention TURN.

Section 7.1:
-    "... transport addresses for each component of each component  
match".
    Delete "for each component" ?

Section 7.2:

-   Must all the components of a given candidate have the same priority?
     Section 7.3 says "yes", but I feel that, to a reader looking for  
this information, section 7.2 would be the
     logical place to look. Suggest mentioning this in section 7.2 as  
well.

-   I think it would be helpful to have a clear statement in this  
section that the prioritization is between
     all the candidates for a single media stream, regardless of  
their  transport type, address type, port, etc.

-       "If the active candidate pair in the initial offer is being  
validated, media will flow to that pair once it is validated."
    Suggest replacing with
        "The active candidate pair in the initial offer is validated  
first, and if that validation succeeds,
          media will immediately begin to flow between the pair."

Section 7.3:
-        "If there is no active candidate, the agent MUST include an  
a=inactive attribute.
           The RTP address and port in the m/c-line is  
inconsequential, since it won't be used."
    In the second sentence, suggest replacing "RTP" by "media", to  
make the statement accurate
    even if something other than RTP is used.

-       "The candidate-id MUST be chosen randomly and contain at  
least 24 bits of randomness
          (this does not mean that  the candidate-id is 24 bits long;  
just that it has at least 24 bits
          of randomness)."
    I personally found this sentence very confusing the first couple  
of times I read it.
    Suggest replacing this with the following text:
         "The candidate ID MUST be chosen randomly and contain at  
least 24 bits of randomness.
          This means that a candidate ID must be at least 4  
characters long, since each character
          in the base64 alphabet used for candidate IDs contains at  
most 6 bits of randomness.
          A candidate ID MAY be longer than 4 characters, and  
different candidate IDs MAY have
          different lengths."

-       "It is needed only to prevent a possible simultaneous selection
          by two agents within a private network for the useful  
lifetime of the
          software or hardware."
     This sentence meant nothing to me until I read the example two  
pages later.
     Perhaps add a note "(For more explanation, see the example later  
in this section)"?

-       "... a unique identifier, call the tid"
   In this section, you use only the term "tid".
   By contrast, in section 7.4 you always write "transport address ID".
   Perhaps, in each section, say  "transport address ID or tid" the  
first time the term appears in that section,
   and then use tid from then on?

-     "The tid gets combined ... to form the username that is placed  
in the STUN checks ...".
    Perhaps mention the "Transport Address Pair ID"? That is, perhaps  
reword as follows:
       "The tid gets combined ... to form the Transport Address Pair  
ID (see section 7.4)
        which is used as the username in the STUN checks ...".

Section 12:

- The rules DIGIT and SP are never defined.
   Suggest stating that they are from section 9 of draft-ietf-mmusic- 
sdp-new

-      "   base64-char           = ALPHANUM / DIGIT / "+" / "/"   "
    Because of the overlap between ALPHANUM and DIGIT,  I suggest it  
would be less confusing to write this as
        "   base64-char           = ALPHA  / DIGIT / "+" / "/"   "
   where ALPHA is also defined in section 9 of draft-ietf-mmusic-sdp- 
new.
   Alternatively, a rule for "base64-char" is defined explicitly in  
section 9 of draft-ietf-mmusic-sdp-new
   (albeit under the comment "      ; sub-rules of 'k='   ").

-  The rule "token" is never defined.
    Presumably you mean "token" as defined in section 9 of draft-ietf- 
mmusic-sdp-new?

-    "                       addr SP     ;addr from RFC 3266    "
   Suggest instead using instead either "unicast-address" or  
"connection-address"
   both of which are defined in section 9 of draft-ietf-mmusic-sdp-new.

- Philip

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic