Document: draft-ietf-sipping-nat-scenarios-08 Reviewer: Ari Keränen [ari.keranen@nomadiclab.com] Review Date: 5/12/2008 Review Due: 5/23/2008 Review Type: WGLC Summary: Overall, I think it's a nice and useful document. Many of the comments are just nits but I suppose they're also welcome at WGLC stage. Comments: --------- The indented text is from the draft, non-indented are my comments. Section 1. large number of potential deployment scenarios. Detail of different s/Detail/Details/ Throughout the text you seem to be using ("traversal of", "getting signaling across", etc.) "NAT" and "NATs" interchangeably -- sometimes even in the very same sentence. I'd always use the latter one in this context (e.g., "traversal of NATs" instead of "traversal of NAT"). 2. (very end) And finally, to complicate the problem even further, a number of different NAT topologies with different default behaviors increases the difficulty of arriving at a single approach. What "single approach" you mean here? 3.1.2. The second problem with sip signaling, as defined in Section 2 and s/sip/SIP/ Guidelines for devices such as User Agents that can only generate outbound connections through a NAT are documented in 'SIP Conventions for UAs with Outbound Only Connections'[I-D.ietf-sip-outbound]. That draft is actually called "Managing Client Initiated Connections in the Session Initiation Protocol". Also, at least I would use a space between the reference and the text (they're quite often stuck together). keep NAT bindings alive. This is achieved by multiplexing a relative ping/pong mechanism over the SIP signaling connection (STUN for UDP and CRLF/operating system keepalive for reliable transports like What do you mean by a "relative" mechanism? 3.2. forward and provide a simple, universal solution for varying types of NAT deployment. s/deployment/deployments/ 3.2.1 used. This involves an SIP endpoint both sending and receiving RTP/ s/an/a/ This section also contains unnecessary repetition. I would change the part overcome this problem, a technique called 'Symmetric' RTP/RTCP can be used. This involves an SIP endpoint both sending and receiving RTP/ RTCP traffic from the same IP Address/Port combination. This technique is known as 'Symmetric RTP/RTCP' and is documented in RFC 4961 [RFC4961]. 'Symmetric RTP/RTCP' SHOULD only solely be used for traversal of RTP through NAT when one of the participants in a media session definitively knows that it is on the public network. to something like overcome this problem, a technique called 'Symmetric RTP/RTCP' [RFC4961] can be used. This involves a SIP endpoint both sending and receiving RTP/RTCP traffic from the same IP address/port combination. 'Symmetric RTP/RTCP' SHOULD only be used for traversal of RTP through NATs when one of the participants in a media session definitively knows that it is on the public network. 3.2.1.1. Normal practice when selecting a port for defining Real Time Control Protocol(RTCP) [RFC3550] is for consecutive order numbering (i.e Put a space between "Protocol" and "(RTCP)" 3.2.2. Simple Traversal of Underneath Network Address Translators(NAT) or You're using the old name of the draft here. It should be "Session Traversal Utilities for NAT". Also, I think some parts of this section should be rephrased. IMHO, what STUN does is described in an unnecessarily complex way. For example, instead of "[STUN] provides details of the external IP address/port combination used by the NAT device to represent the internal entity on the public facing side of a NAT" one could say something like "[STUN] enables a host behind a NAT to discover the address and port that the NAT allocated for it". 3.2.3. 'Obtaining Relay Addresses from Simple Traversal of UDP Through NAT (known as TURN)' is a usage of the STUN protocol for deriving (from a STUN server) an address that will be used to relay packet towards a client. The TURN usage is nowadays called "Traversal Using Relays around NAT". Also, you should talk about a TURN (not STUN) server in this section. Also: s/packet/packets/. And also, TURN server will relay the packets to the other direction too, not just "towards a client". STUN server that will act as a media relay which guarantees traffic will reach the associated internal address. The full details of the "guarantees traffic will reach" is quite strong wording here. Relay does relay the packets but does not guarantee reachability by any means (AFAIK). it is RECOMMENDED that this method only be used as a last resort and add a "would" between "method" and "only"? 3.2.4. appropriate. ICE is a methodology for using existing technologies such as STUN, TURN and any other UNSAF[RFC3424] compliant protocol to What "any other UNSAF" protocols are you referring to here? ICE can also use, e.g., VPN addresses and, AFAIK, they're not "UNSAF compliant". technologies such as STUN/TURN etc. Once the addresses are No need for the "etc" here since you already use "such as", right? has detailed connection information including a media addresses, priority, transport. s/addresses/address/ s/, transport/and transport protocol/ are used in the correct order depending on the specified priority. A client compliant to the ICE specification will then locally run instances of STUN servers on all addresses being advertised using The "correct order" wording is a bit strange here; better would be something like "ordered by their priorities". And the "[multiple] instances of STUN servers" gives, IMHO, a wrong impression: normally there's just a single process, the ICE thing, that happens to be listening to many ports for STUN traffic. Same issue is repeated at least in the bullets after the Figure 10. 3.2.5.2. an Address Dependant or Address and Port Dependant NAT, although it Instead of "dependant", I would use "dependent" since that's the form used in, e.g., RFC4787. Also, you're mixing the old terminology (symmetric NAT) with the new one. Maybe it's better to use only the new terminology? 4.2.1.1.1. |<-----------------| | | |Src=STUN-PUB | | | |Dest=L-PRIV-1 | | | |XOR=NAT-PUB-1 | | | s/XOR/Map/ 4.2.1.2.1. L NAT STUN NAT R Server s/STUN/TURN/ | |(2) Alloc Req | | | | |Src=L-NAT-PUB-1 | | | | |Des=STUN-PUB-1 | | | s/Des/Dest/ |(5) STUN Req | | | | s/STUN/Alloc/ |===================================================================| |>>>>>>>>>>>>>>>>>>>>>Outgoing RTP sent from >>>>>>>>>>>>>>>>>>>>>>>| |===================================================================| s/from/from L-PRIV-1/ (also for RTCP) |===================================================================| |<<<<<<<<<<<<<<<<<<<<