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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Jun 2006 23:20:56 -0400

responses inline.

Philip Matthews wrote:

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

Its not allowed in base ICE, which is specific to UDP. But ice-tcp 
allows it, and that is explained there in more detail.

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

Yes. Again in ICE there is no choice since its UDP only.

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

any order. I'll clarify.

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

Well, that depends. To date I've been keeping references to rfc2327 to 
avoid normative ref hold at rfc-ed. SDP-new has been a long time coming. 
Its finally approved now, and indeed looks like its in auth48 so we're 
close. I'll change the reference.

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

Right. Indeed this is a critical aspect of the specification. I added a 
paragraph in the intro which reads:

It's important to point out that, when used with ICE, an agent will
always send and receive media on the same transport address. That is,
if an agent includes a transport address of 192.0.2.1:2444 in its SDP
for receiving RTP packets (and also STUN connectivity checks). It will
not only receive STUN requests and RTP packets on this transport
address, it will also send STUN requests and RTP packets from this
transport address. This property, known as symmetric RTP, is essential
for proper operation of ICE. Peer reflexive transport addresses,
discussed further below, will generally only work when symmetric RTP
is used. Symmetric RTP is also key for keeping NAT bindings alive.

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

done.

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

done.

> 
> Section 7.2:
> 
> -   Must all the components of a given candidate have the same priority?

yes.

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

Well, I'll mention in 7.2 but it really doesn't belong there. 7.2 is 
quite explicitly about candidates, and not components. Not sure why 
someone would look in 7.2 for information about components.

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

I updated the first sentence of this section to read:

<t>The prioritization process takes the set of candidates for a
particular media stream and associates each with a priority. This

so its clear we're talking about a single media stream.

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

ok.

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

fixed.

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

ok.

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

I'd rathre avoid a forward reference. The beefier tutorial now mentions 
the ordering of the candidate pairs and indeed mentions the candidate ID 
for tie breaking. Thus, I can mention that in the explanation, which now 
reads:

same candidate MUST use the same candidate ID used previously. 24 bits
is sufficient because the candidate ID is not providing security (the
much more random password is). Its sole purpose is to make it highly
unlikely that both the offerer and answerer select the same value for
a candidate for the same media stream. Different values for the
candidate ID are required to break ties in the procedure that is used
to order the candidate pairs.
</t>

> 
> 
> -       "... 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 convention I'm now using is that the only place "tid" is used is in 
the figures where it is too compact to expand it.

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

see above.

> 
> 
> Section 12:
> 
> - The rules DIGIT and SP are never defined.

They are defined in RFC 4234, which is referenced prior to the BNF as 
the source of the rules.

>   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 / "+" / "/"   "

agree - good catch.

>   where ALPHA is also defined in section 9 of draft-ietf-mmusic-sdp- new.

ALPHA is also defined in RFC 4234.

>   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='   ").

I think defining it here as using ALPHA and DIGIT is the clearest.

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

no, from rfc 3261. The text below says that token is from rfc3261 but 
its not in the comments. I added a comment in the grammar.

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

I'll use connection-address. ICE isn't defined for multicast but no 
reason to have the syntax rule it out.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

From: Philip Matthews <[email-masked]>
Date: Fri, 23 Jun 2006 13:20:29 -0400

Jonathan:

Thanks for your reply.
I am quite happy with most of what you said.
Comments on a couple of points below.

- Philip

On 20-Jun-06, at 23:20 , Jonathan Rosenberg wrote:
>> 1)  Can a single offer contain candidates for the same media  
>> stream  that use different transport protocols??

This doesn't seem right to me.
In my opinion, draft-ietf-mmusic-ice is both the base specification  
for ICE and the specification that
defines the rules for UDP. In this regard, the general rules for  
mixing candidates with different transport protocols
belong in draft-ietf-mmusic-ice, and not in some extension document.
So why do you think they belong in ice-tcp instead?

[---SNIP---]

Regarding the following three exchanges:
> They are defined in RFC 4234, which is referenced prior to the BNF  
> as the source of the rules.

... and ...

> ALPHA is also defined in RFC 4234.

... and ...

>>    Presumably you mean "token" as defined in section 9 of draft- 
>> ietf- mmusic-sdp-new?
>
> no, from rfc 3261. The text below says that token is from rfc3261  
> but its not in the comments. I added a comment in the grammar.

Personally, I think that taking these rules from documents other than  
draft-ietf-mmusic-sdp-new is wrong.
ICE is an SDP extension, so it is bound by the rules of SDP.
Though it may not have an impact on the actual grammar, I think it is  
much clearer to the reader if it was
stated than the grammar of section 12 is just an extension of the  
grammar given in draft-ietf-mmusic-sdp-new
and that any rules not defined in the ICE document are defined there.