This document is an impressive tour de force of how NAT works with SIP and
with media.
The IPv6 scenario in Section 6 needs updating to include TURNv6 or a
discussion of why TURNv6 is not the BCP; we may want to remove the NAT64 that
is in the current Section 6, but I'm not sure.
Other than than, I didn't find anything earth-shattering but several of my
suggested changes will resolve internal inconsistencies in the document, and
correct what I believe are technical errors.
-d
-----
Section 1,
The IETF has been active on many specifications for the traversal of
NATs, including STUN[I-D.ietf-behave-rfc3489bis],
ICE[I-D.ietf-mmusic-ice], symmetric response[RFC3581], symmetric
RTP[RFC4961], TURN[I-D.ietf-behave-turn], SIP
Outbound[I-D.ietf-sip-outbound], SDP attribute for RTCP[RFC3605], and
others.
Consider adding draft-ietf-avt-rtp-and-rtcp-mux to that list (it is
already mentioned later in the document).
The best practices described in this document are for traditional
"client- server"-style SIP. It seems likely that other groups using
SIP, for example P2PSIP, will recommend these same practices between
a P2PSIP client and a P2PSIP peer, but will recommend different
practices for use between peers in a peer-to-peer network.
To many non-SIP people, SIP is already a peer-to-peer protocol
(because it started out that way). I don't have a suggestion to
improve the paragraph, but some further discussion about how SIP
is really client/server where UAs talk to their own proxies and
not directly to other SIP UAs (thus making it client/server) seems
worth a sentence.
Also if there is a citation for P2PSIP, that would be useful; as is,
I expect in 5-6 years someone reading this won't know what "P2PSIP"
meant.
Section 3,
This document assumes NATs that do not contain SIP-
aware Application Layer Gateways (ALG). Some NATs that are available
today contain such behavior that which makes much of the issues
discussed in the document not applicable.
The 'such behavior' phrase in second sentence is vague; how about
just tightening that up to:
This document assumes NATs that do not contain SIP-
aware Application Layer Gateways (ALG), which makes much of
the issues discussed in the document not applicable.
Which begs the question: why not just promote ALGs instead of
this 61 page document? A discussion of the drawbacks of ALGs
might be valuable here.
Section 3,
In Figure 2 the original REGISTER request is sent from the client on
port 8023 and received on port 5060, establishing a connection and
^
insert "by the proxy"
opening a pin-hole in the NAT.
Section 3,
Figure 3 should show a proxy between the two Clients, so that it is
clear how their SIP signaling is established. This can be done
by replacing "->---<-" with ">Proxy<".
Section 3,
The connection addresses of the clients behind the NATs will
nominally contain a private IPv4 or IPv6 address that is not routable
^^^^^^^
delete "or IPv6"
across the public Internet.
Section 3,
In general the problems associated with NAT traversal can be
categorized as follows.
...
For media:
o Each endpoint has a variety of addresses.
^
^
add "addresses that can be used to reach it (e.g., native
interface address, public NATted address)."
o Many NATs filter inbound packets if the local endpoint has not
recently sent an outbound packet to the sender [same problem as
^^^^^^^^^^^^^^^^
second one under signaling].
^^^^^^^^^^^^^^^^^^^^^^^^^^^
It isn't quite the same problem; the second problem under signaling -- we
could imagine a long-term connection between a UA and its proxy, but we cannot
imagine a long-term connection between a UA and *all* potential peers on the
Internet. I would simply remove the bracketed sentence.
Section 4,
Overall, I think it would be useful for all solutions in Section 4 to indicate
if they can be implemented by only the SIP UA initiating the request, only the
proxy, or need to be implemented by both UAs.
The text reads:
As mentioned previously, the traversal of SIP through existing NATs
can be divided into two discrete problem areas: getting the core
^^^^
replace "core" with "SIP"
signaling across NATs,
Section 4.1.1,
The first paragraph of 4.1.1 seems to re-state the problem which seems
unnecessary as we have a separate problem section (Section 3) and solution
section (Section 4). The text does not describe the solution depicted in
Figure 4, but the last two sentences of the paragraph describe the solution
depicted in Figure 4:
This
results in the pin-hole opened for the requests traversal of the NAT
being reused, in a similar manner to that of reliable connection
orientated transport protocols such as TCP. Figure 4 illustrates the
response traversal through the open pin hole using this method.
I think there was a cut-and-paste error? The quick summarizing of the
problem, as done in the first paragraph of Section 4.1.2, seems adequate and
correct.
Section 4.1.1,
Figure 4 shows Client A talking to Client B. I would call this "peer to peer
SIP" rather than "Client/Server SIP". I suggest changing the right-hand side
thing to a SIP proxy.
Section 4.1.1,
Even if the SIP Outbound draft is not used, clients generating SIP
requests SHOULD use the same IP address and port (i.e., socket) for
both transmission and receipt of SIP messages. Doing so allows for
the vast majority of industry provided solutions to properly
function. Deployments should also consider the mechanism described
^
^
insert "(e.g., SBC hosted NAT traversal)"
in the Connection Reuse[I-D.ietf-sip-connect-reuse] specification for
routing bi-directional messages securely between trusted SIP Proxy
servers.
Section 4.2.1,
'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 and is using a
'latching' technique as described in
[I-D.ietf-mmusic-media-path-middleboxes]. Symmetric RTP/RTCP is
important for everything that might want to traverse a NAT or speak
with an endpoint that is behind a NAT - even if the remote endpoint
is an SBC performing 'hosted NAT traversal'.
My interpretation of that sentence is that symmetric RTP/RTCP should
*not* be used in other cases (e.g., when using ICE). I don't believe
that was intended. Flip the sentence around and the intended meaning
is clear:
When operating behind a NAT and using the 'latching' technique
described in [I-D.ietf-mmusic-media-path-middleboxes], SIP user
agents SHOULD implement 'Symmetric RTP/RTCP'. This allows traversal
of RTP across the NAT.
I would delete the last sentence of the paragraph (the one starting
with "Symmetric RTP/RTCP is important ...".)
Section 4.2.2,
This
assumption causes RTCP traffic to break when traversing certain types
of NATs due to blocked ports.
^^^^^^^^^^^^^
replace with "various reasons (e.g., already-allocated
port, randomized port allocation)."
Section 4.2.2,
The use of RFC 3605 [RFC3605] MUST be supported.
I don't think this is a MUST, if the SBC is doing 'latching' and provides
RTP+1 port for RTCP. There are other exceptions in this BCP for SBCs that
allow softening, so we should remove them all (and be silent on it) or align
them all to talk about SBC operation explicitly.
An alternative
mechanism defined in [I-D.ietf-avt-rtp-and-rtcp-mux] specifies
'muxing' both RTP and RTCP on the same IP/PORT combination. Using
this technique eliminates the problem but is still immature.
I don't understand how RTP/RTCP multiplexing 'eliminates the problem' -- both
SIP UAs have to support RTP/RTCP (a=rtcp-mux). RTP/RTCP might have been
immature when the 'still immature' clause was written but it's in RFC editor's
queue now and several I-Ds are referenced which have not progressed that far.
I also wouldn't quite consider RTP/RTCP multiplexing an 'alternative' to
RFC3605 -- rather words like 'further enhancement' or 'an additional
optimization is available with [rtcp-mux]'. At least it isn't an
'alternative' until there are a lot of implementations of rtcp-mux. For quite
awhile we will need both (as RFC3605 is what is deployed today). Fortunately,
there is good backwards compatibility with RFC3605 and RTP/RTCP multiplexing.
Section 4.2.3.1,
The IP address/port
combination deduced for the STUN server would be blocked for incoming
packets from an alterative SIP entity.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
too vague. Suggest replacing with "RTP packets from the
remote SIP user agent."
Section 4.2.3.2,
TURN provides an external address
(globally routable) at a STUN server that will act as a media relay
^^^^
TURN
which attempts to allow traffic to reach the associated internal
address.
(I think we decided to just stick with "TURN server" for a TURN server, rather
than "A STUN server following the TURN usage".)
Section 4.2.3.3,
Interactive Connectivity Establishment (ICE) is the RECOMMENDED
method for traversal of existing NATs if Symmetric RTP is not
appropriate.
^^^^^^^^^^^
replace with "sufficient (e.g., there isn't an SBC
performing 'latching')."
Section 4.2.3.3,
(*note - an ICE endpoint can also use
non-IETF mechanisms (e.g., NAT-PMP, UPnP IGD) to learn public IP
^^^^^^^^
replace "non-IETF" with "other". (NAT-PMP is arguably an "IETF
mechanism", even though it is an individual I-D.)
Section 5.1.1.2,
It could just be me, but I'm confused when the section is titled
"Connection Oriented Transport" and then goes to discuss "reliable
transport". The advent of DCCP, which is connection oriented but
unreliable makes me wonder "but what of DCCP". Of course, we all
know that DCCP does not enjoy much support in NATs today so it
is probably reasonable to declare it out of scope for this document
but it makes me wonder if we should be more clear and just say
"UDP" (rather than "unreliable") in the entire document and
"TCP" (rather than "reliable" or "connection-oriented" or
"reliable, connection-oriented" -- all three seem to be used).
Section 5.1.2,
In Figure 7, I believe the 'outbound connection tuple' is
created after the Edge Proxy receives the REGISTER? As
currently depicted, it appears that the tuple is remembered
only after the REGISTER message is received at the Registrar.
Section 5.1.3.1,
"funcationality" -> "functionality"
Section 5.1.4.1,
The proxy then examines the request
URI of the INVITE and compares with its list of
current open flows.
^^^^^^^^^^
This the first use of the term "open flows". Media "flows", but this sentence
is talking about signaling. How about "with its list of connection tuples" or
"its list of bindings", either of which is more congruent with the text in
previous sections.
Once matched, the proxy checks to see if the
unique instance identifier (+sip.instance) associated with the
binding equals the same instance identifier associated with the flow.
^^^^^^^^
I suggest "with that connection tuple"
The request is then dispatched on the appropriate flow.
^^^^
"binding" might be better.
5.2.1,
The section title and body mention "Endpoint Independent NAT". However,
RFC4787 is more specific and includes 'filtering' or 'mapping'; that is, it
defines "Endpoint independent filtering NAT' and 'endpoint independent mapping
NAT'. I realize the terms are long and awkward, but if you want to use
something shorter you might consider saying something like "The use of
'Endpoint Independent NAT' in this document [section?] means a NAT that is
both 'Endpoint Independent Filtering NAT' and 'Endpoint Independent Mapping
NAT' per RFC4787's definition", or perhaps use an acronym such as "EIF". (It
is true that endpoint independent filtering requires endpoint independent
mapping, and that might be another way of keeping the wording shorter).
In the top of 5.2.1, I suggest pointing out there is no reliable test to
determine if you are behind an 'endpoint independent filtering' or 'endpoint
independent mapping' NAT. Citing draft-ietf-behave-nat-behavior-discovery
would be useful. Something like:
At this time there is no reliable test to determine if a host is
behind an 'endpoint independent filtering' NAT or an
'endpoint independent mapping' NAT
[I-D.draft-ietf-behave-nat-behavior-discovery], and the sort of
failure that occurs in this situation is described in Section
5.2.2.1. For this reason, ICE is RECOMMENDED over the mechanism
described in this section.
Section 5.2.1.1.1,
The following example demonstrates media traversal through a NAT with
'Address-Independent' properties using the STUN 'Binding Discovery'
usage.
"'Address-Independent' properties" are not defined in this document, nor
in RFC4787. I *believe* that "Endpoint-Independent Mapping" is what
is wanted here, but I'm not completely sure; please consult RFC4787
for the terminology that you wanted here.
Section 5.2.1.2,
5.2.1.2. ICE Solution
The preferred solution for media traversal of NAT is using ICE, as
described in Section 4.2.3.3, regardless of the NAT type. The
following examples illustrate the traversal of an 'Endpoint
Independent' NAT when initiating the session. The example only
covers ICE in association with the 'Binding Discovery' and TURN.
I would point out the TURN server provides both STUN functions (to learn your
public mapping) and TURN functions (media relaying).
I would also point out that while the example shows both "L" and "R"
contacting the same TURN server [sic, see my comment regarding 5.2.1.2.1],
this is not necessary for ICE, STUN, or TURN to function; all that is
necessary is that the STUN server and TURN server(s) be in the same addressing
domain -- that is, accessible on the Internet.
5.2.1.2.1,
This example is for an 'Endpoint independent' NAT, which doesn't utilize the
TURN server. The signaling shown also does not allocate a port from the TURN
server. So, I think the device in the middle of Figure 13 is really a plain
old STUN server.
The client would be free to gather any number of
external representations using any UNSAF[RFC3424] compliant
protocol.
That statement is too restrictive; just say "The client can also gather IP
addresses and ports via other mechanisms (e.g., NAT-PMP, UPnP IGD)." or
similar.
Section 5.2.2.2, "TURN Solution"
The term defined in RFC4787 is "Address and Port-Dependent Mapping".
Abbreviating it slightly to use "/" instead of "and" is fine but I would
maintain the same word order (that is, use "Address/Port-Dependent").
As identified in Section Section 5.2.2.1, STUN provides a useful tool
for the traversal of the majority of NATs but fails with Port/Address
Dependent NAT. The TURN extensions [I-D.ietf-behave-turn] address
this scenario. TURN extends STUN to allow a client to request a
relayed address at the TURN server rather than a reflexive
representation. This then introduces a media relay in the path for
NAT traversal (as described in Section 4.2.3.2). The following
example explains how TURN solves the previous failure when using STUN
to traverse a 'Port/ Address Dependent' type NAT.
It should be noted that TURN works best in conjuncation with ICE.
Without ICE, all media is relayed through the TURN server.
The figure here, Figure 19, shows a STUN server but should show a TURN server.
Section 5.2.2.3,
ICE makes use of core STUN, TURN and any other
UNSAF[RFC3424] compliant protocol to provide a list of prioritized
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
replace with "mechanism (e.g., NAT-PMP, UPnP IGD)"
Section 6,
6. IPv4-IPv6 Transition
This section describes how IPv6-only SIP user agents can communicate
with IPv4-only SIP user agents. While the techniques discussed in
this draft primarily contain examples of traversing NATs to allow
communications between hosts in private and public networks, they are
by no means limited to such scenarios. The same NAT traversal
techniques can also be used to establish communication in a
heterogeneous network environment -- e.g., communication between an
IPv4 host and an IPv6 host.
Figure 21 shows a "SIP phone" at the top and an "IPv6 SIP UA" at the
bottom; is there a significance to using different terminology?
The NAT in Figure 21 is "not your father's NAT" -- it translates
from IPv6 to IPv4. This should be highlighted in the text; this
is I guess a NAT-PT device? Or the NAT64 device that BEHAVE is
standardizing? I am surprised the document shows such an
address family translator as the Best Current Practice. Afterall,
we do have IPv4 and IPv6 support in TURN and TURN-v6, and I would
like to see another scenario where TURN is used to interwork
between v4 and v6.
**end of dwing's review**
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
