draft-rosenberg-midcom-turn-07

Some comments on TURN-07:


Section 5, 3rd paragraph:

"The TURN Server is responsible for guaranteeing that packets sent to PA
route to the TURN server."

I think it should be "...route to the TURN client."


Section 7.2.2, 10th paragraph:

"That response MAY include an ALTERNATE-SERVER attribute..."

I think that it will be easier to manage pools of TURN servers if it is
possible to return a list of IP addresses instead of only one IP
address. In this case the client must not retry to contact a TURN server
that already sent a 300 response, even if the IP address is in the list
(This is similar to the processing of a 3xx response with multiple
contacts in a SIP UAC).


Section 7.2.2, 15th paragraph:

I think that the Allocate Response must start with a MAGIC-COOKIE attribute.


Section 7.2.2 20th paragraph:

I am not sure what this paragraph means. Perhaps it is something from a
previous draft?


Section 7.2.3, 2nd paragraph:

What response code must be used if the username does not match the
username in the selected binding?


Section 7.3, 7th paragraph:

Should the Send Response message have a MESSAGE-INTEGRITY attribute?


Section 7.4, 2nd paragraph:

I think that the Data Indication message must start with a MAGIC-COOKIE
attribute.
Also the Data Indication message should end with a MESSAGE-INTEGRITY
attribute.


Section 7.4, 7th paragraph:

"If there is a match, the the UDP packet..."


Section 8.1, 2nd paragraph:

Perhaps some error responses should also trigger a new request to the
next element in the list, e.g. when receiving a 300 Error Response
without an ALTERNATE-SERVER attribute.


Section 8.6, 4th paragraph:

"If the response code is 438..."

It looks like this is from a previous draft, as lock-down no longer
exist in this draft.


Section 8.8, 2nd paragraph:

"Any UDP packets recieved by the server..."


Section 9.2:

The REALM attribute is not defined.
SOURCE-ADDRESS is already defined in STUN, with a different number.


It also can be useful to have a way to received the IP address/port
allocated in the NAT, in the Allocate Response (= the MAPPED-ADDRESS in
the Binding Response). This way we can have one request to allocate the
STUN binding on the NAT and the TURN port, both from the same port on
the client. And this creates only one binding on the NAT, instead of two
if STUN and TURN are used separately.

-- 
Marc Petit-Huguenin
Home: [email protected]
Work: [email protected]