Subject: [MMUSIC] AD evaluation: draft-ietf-mmusic-rtsp-nat-20

From: Alissa Cooper <[email-masked]>
Date: Thu, 22 May 2014 15:42:23 -0400

I have reviewed draft-ietf-mmusic-rtsp-nat-20 in preparation for IETF LC.
The document is in good shape. I have a few questions and comments below
that need to be resolved before issuing the last call. I’ve also included
a list of nits that should be resolved in the next rev.

Comments and questions:

Sec 4.2:
"The connection address SHOULD use the same format
      (explicit IP or FQDN) as in the dest_addr parameter used to
      express fallbacks.”

Per 4.1, I thought the dest_addr MUST NOT be included, so this requirement
seems contradictory.

"<tcp-type-ext>:  conveys the candidates connection type (active,
      passive, or S-O) for TCP based candidates.  This MUST be included
      for candidates that have <transport> set to TCP and MUST NOT be
      included for other transport types, including UDP, unless
      explicitly specified for that transport protocol."

I’m assuming the last phrase means “unless <something> gets specified in
the future for that transport protocol.” But I’m not clear on what the
<something> is.

Sec 4.4:
"The RTSP client SHOULD send the feature tag "setup.ice-d-m" in the
   "Supported" header in all SETUP requests that contain the "D-ICE"
   lower layer transport.”

What are the situations where the SETUP request contains “D-ICE” but where
the feature tag should not be included? Is it for SETUP requests issued
after media is already playing (as described in Sec 6.13)?

Sec 6.5:
"The server determines if the SETUP request is successful from the
   other perspectives”

It’s not clear what is meant by “from the other perspectives.”

Sec 6.10:
"If the 480 response is received or sent in response to a PLAY
   request, the server MUST NOT free its gathered candidates."

The “received or sent” part doesn’t quite make sense, since we’re talking
about the server, right? Shouldn’t this just say “sent”?

Sec 6.13:
See comments on Sec 4.4 above — why is the Supported header not included
in the SETUP requests in this example?

Sec 7.1 and 7.2:
Again with reference to Sec 4.4 — why is the "setup.ice-d-m” feature tag
mandatory for media proxies but recommended for clients and signaling
proxies?

Sec 7.3:
"Unfortunately, the usage of the "setup.ice-d-m" feature tag in the
   Proxy-Require will have contradicting results.”

This sentence and the paragraph that follows are confusing because there
is no prior mention of putting the feature tag in the Proxy-Require header
(although I guess it was implicitly assumed). I think what you meant is
this:

"The usage of the “setup.ice-d-m” feature tag in the Proxy-Require header
is NOT RECOMMENDED because it can have contradictory results.”

Sec 8:
"This multiplexing SHALL be combined with ICE”

I think s/ICE/ICE-RTSP/ makes sense here.

"Due to the above mentioned benefits, RTSP servers and clients that
   support "D-ICE" lower layer transport in combination with RTP SHALL
   also implement RTP and RTCP multiplexing as specified in this section
   and [RFC5761].”

Multiplexing is not specified in this section. Did you mean as specified
in Appendix C of draft-ietf-mmusic-rfc2326bis and RFC5761?

Nits:

There are a couple of idnits that should be fixed.

Sec 1:
s/when PLAY request are/when PLAY requests are/

Sec 4.2:
OLD:
<foundation>:   is an identifier that is equivalent for two
      candidates that are of the same type, share the same base, and
      come from the same STUN server, and is composed of one to thirty
      two <ice-char>.

NEW:
<foundation>:   is an identifier that is equivalent for two
      candidates that are of the same type, share the same base IP
address, and
      come from the same STUN server. It is composed of 1 to 32
<ice-char>s.

s/is used when the second component/is used, in which case the second
component/

s/the Allocate Response/the TURN Allocate Response/

s/<tcp-type-ext>:  conveys the candidates connection type/<tcp-type-ext>:
conveys the candidate’s connection type/

Sec 4.4:
s/RTSP agents; clients, servers and proxies./RTSP agents: clients, servers
and proxies./

Sec 6.12:
s/First, if it can attempt/First, it can attempt/

s/or change the transport parameters./or changing the transport
parameters./

s/SHALL use Regular nomination./SHALL use regular nomination./

Sec 6.13:
s/A Server/A server/

s/gather new ICE candidates, and send/gather new ICE candidates and send/

s/If not the client will/If not, the client will/

Sec 7.3:
s/non ICE/non-ICE/

OLD:
A non-media handling proxy is expected to ignore and simply forward
   all unknown transport specifications, however, this can only be
   guaranteed for proxies following the RTSP 2.0 specification
   [I-D.ietf-mmusic-rfc2326bis].

NEW:
A non-media handling proxy is expected to ignore and simply forward
all unknown transport specifications. However, this can only be
guaranteed for proxies following the RTSP 2.0 specification
[I-D.ietf-mmusic-rfc2326bis].

s/if you want to provide other fallbacks/if it is desirable to provide
other fallbacks/

s/For non-supporting non-media handling proxies the result will also
result in aborting the setup, however,/For non-ICE supporting non-media
handling proxies the result will be aborting the setup. However,/

s/the proxy chain support/the proxy chain supports/

s/to try perform an SETUP/to try to perform a SETUP/

Sec 9:
OLD:
However, for RTSP clients lacking a relay server,
   like a TURN server, or where usage of such a server has significant
   cost associated with it the usage of a STUN derived server reflexive
   address

NEW:
However, for RTSP clients lacking a relay server,
such as a TURN server, or where usage of such a server has significant
cost associated with it, the usage of a STUN-derived server reflexive
address

s/the selected protocol, e.g. UDP needs/the selected protocol, e.g. UDP,
needs/

s/Secondly the selected/Secondly, the selected/

Sec 10.1:
s/This document request that/This document requests that/

s/ICE based/ICE-based/

Sec. 10.2:
s/Transport Protocol Specifications/Transport Protocol Identifiers/

Sec 12:
s/Bill Atwood have provided/Bill Atwood has provided/

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 27 May 2014 11:59:09 +0200

Hi,

Thanks for the review. Please see below for answers and comments on your
questions and comments.

> Per 4.1, I thought the dest_addr MUST NOT be included, so this requirement

So, this is a reference to another transport specification used as
fallback if ICE isn't supported. The format of the D-ICE transport
spec's connection-address SHOULD be the same format (explicit IP or
FQDN) as used in that fallback transport specification's dest_addr
parameter.

Will see what we can do to clarify that it is referencing another
transport spec.

> the future for that transport protocol.” But I’m not clear on what the

So, if anyone defines a new transport protocol and you like to add this
here. Then that protocol may chose to re-use this header. That is when
that unless occurs. As one can define a new parameter as easily, I guess
this "unless ..." is quite unnecessary and can be removed.

> after media is already playing (as described in Sec 6.13)?

I would classify this SHOULD as: we have no good reason why you would
not include the feature tag. But if you have one, we don't see a reason
for making the implementation violate a MUST.

> It’s not clear what is meant by “from the other perspectives.”

As a SETUP for a media resource also the preparation and availability of
the media resource, not only the transport needs to be fulfilled. It
might be clear to simply use "is successful"

> about the server, right? Shouldn’t this just say “sent”?

Correct, as currently specified the 480 is only sent in Server -> Client
direction, thus the "received or" is to be removed.

> in the SETUP requests in this example?

I don't think there exist a reason, just a missed inclusion. will address.

> mandatory for media proxies but recommended for clients and signaling

Because a client really needs to know if a proxy supports the ICE-D
transport. If it doesn't you end up in all the issues discussed in
Section 7.3. If there is one change I think should be done here is to
make 7.2 a SHALL indicate its capability. I also clarified that this
relates to SETUP request and responses.

If a client skips including a Supported header but anyway tries using
ICE-D as transport, it will work if the nodes support it. Including the
Supported header will only make it clear on the feature negotiation
level that the feature is supported and also prompt the proxies to
include their Proxy-Supported header.

> is NOT RECOMMENDED because it can have contradictory results.”

Yes, the sentence you propose is better, will include. The text is
written with the assumption that one knows RTSP 2.0 and its feature
negotiation mechanisms. Thus, clearly one can include the feature tag in
any headers that uses feature tags when relevant.

> I think s/ICE/ICE-RTSP/ makes sense here.

I actually removed the SHALL, it was duplicate with the SHALL in the
last sentence. So I change this to "This multiplexing is very benefical
when be combined with ICE for RTSP as it makes RTP and RTCP need only a
single component ..."

> in Appendix C of draft-ietf-mmusic-rfc2326bis and RFC5761?

Yes, will address.

We will take care of the nits.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 27 May 2014 16:24:23 -0700

Hi Magnus,

Thanks. Comments inline.

>Will see what we can do to clarify that it is referencing another

Thanks.

>this "unless ..." is quite unnecessary and can be removed.

Sounds good.

>for making the implementation violate a MUST.

Would help to explain that rationale in the document.

>might be clear to simply use "is successful"

Agreed.

>direction, thus the "received or" is to be removed.

Ok.

>I don't think there exist a reason, just a missed inclusion. will address.

Ok.

>relates to SETUP request and responses.

Good, this makes sense to me.

>any headers that uses feature tags when relevant.

Ok.

>when be combined with ICE for RTSP as it makes RTP and RTCP need only a

Ok. 

>> in Appendix C of draft-ietf-mmusic-rfc2326bis and RFC5761?

Ok.

>We will take care of the nits.

Great, thanks.
Alissa

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 28 May 2014 15:47:35 +0200

> Would help to explain that rationale in the document.

I propose the following:

   The RTSP client SHOULD send the feature tag "setup.ice-d-m" in the
   "Supported" header in all SETUP requests that contain the "D-ICE"
   lower layer transport.  Note, this is not a "MUST" due to that an
   RTSP client always can attempt to perform an SETUP using ICE to see
   if it functions or fails.  But including the feature tag in the
   "Supported" header do ensure that proxies supporting this
   specification do explicitly indicate such support, see Section 7.

Cheers

Magnus Westerlund

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 28 May 2014 09:04:13 -0700

>   specification do explicitly indicate such support, see Section 7.

Looks good.
Thanks,
Alissa