Re: draft-rosenberg-midcom-turn-07

Section 7.2.2, 1st paragraph:

"A TURN server MUST be prepared to receive Binding Requests over TCP and 
UDP."

Should be

"A TURN server MUST be prepared to receive Allocate Requests over TCP 
and UDP."


Marc Petit-Huguenin wrote:
> 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]
Professional: [email protected]
Work: [email protected]