Subject: [Sipping] Comments on sipping-nat-scenarios-07

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 19 Sep 2007 16:56:21 -0400

Howdy,
Some comments on the draft:

Section 3.1.2 says: "This is achieved using peer-to-peer STUN multiplexed
over the SIP signaling connection."  Per the latest outbound draft and
agreement in Prague(?), that is only for UDP.  For TCP one can use TCP
keepalives, and for TCP or SCTP one can use double-CRLF.  Also, such STUN
use for SIP/UDP in outbound is not "peer-to-peer", it's client-to-server.

Section 3.2.1.1 says to use the RTCP attribute from RFC 3605, since RTCP
uses a separate port number.  It says one needs to use this attribute,
because assuming just the +1 port number "...causes RTCP traffic to break
when traversing many NATs due to blocked ports."  The wording in the section
is a bit misleading - it's not the SDP attribute that fixes the issue, it's
the fact that one sends something out on the RTCP port and thus creates a
NAT binding, and the attribute just tells the other end what that binding
resulted in so they can send RTCP to that port.  But that's not my real
concern - I think we should (instead?) be advocating the RTP/RTCP port
muxing draft from AVT (draft-ietf-avt-rtp-and-rtcp-mux-07.txt) currently in
the RFC editor's queue.  

Section 3.2.3 says "A TURN service will almost always provide media traffic
to a SIP entity but it is RECOMMENDED that this method only be used as a
last resort and not as a general mechanism for NAT traversal."  I think this
may be a bit confusing.  If I recall right, ICE recommended the UAC to
always get TURN-derived addresses for the initial ICE offer, because it had
the highest chance of success.  In fact I thought that was the address used
in the m= line to begin with, just in case the far-end UAS did not support
ICE.  It would be set at a low priority, though, I think.  But the point is
a TURN address should be allocated, but only used if the other ICE
connectivity checks fail. (or if local policy tells you to prefer it)

Section 3.2.5 "Solution Profiles".  I think this section should be removed
entirely.  This just looks like marketing labels to me.  I don't understand
what value they have from a BCP or RFC perspective.  This isn't meant to be
a PICS proforma, is it?

Section 4, the scenarios.  This is a bit of a nit, but I think all of the
example messages should use an IP Address in the contact URI and Via.  I
don't think I have ever seen an FQDN in a contact.  And for NAT traversal
examples in particular, that's one of those differences that make it
"unique" from non-NAT call flow scenarios.

Section 4.1.4.1 has a malformed sip request-uri for the second example
Invite.

Section 5.2 says to use ANAT for IPv4-IPv6.  I believe ANAT was denounced at
the Prague IETF and ICE must be used instead.  This section needs to be
re-done to show ICE usage instead.

Overall - the words "connection reuse" are used when you really mean
Outbound (connection-reuse is a different draft).  For example "Connection
Re-use Tuple" throughout section 4, and it's even described as the
"Connection Re-use draft" in 4.1.1.2.

-hadriel

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 26 Sep 2007 12:20:40 +0100

[Chris Boulton] Hi Hadriel - thanks for the comments.  More in-line.

Chris.

p.s. Jonathan - there is one embedded for you.

Howdy,

Section 3.1.2 says: "This is achieved using peer-to-peer STUN
multiplexed
over the SIP signaling connection."  Per the latest outbound draft and
agreement in Prague(?), that is only for UDP.  For TCP one can use TCP
keepalives, and for TCP or SCTP one can use double-CRLF.  Also, such
STUN
use for SIP/UDP in outbound is not "peer-to-peer", it's
client-to-server.

[Chris Boulton] Agreed that this needs to be expanded.

Section 3.2.1.1 says to use the RTCP attribute from RFC 3605, since RTCP
uses a separate port number.  It says one needs to use this attribute,
because assuming just the +1 port number "...causes RTCP traffic to
break
when traversing many NATs due to blocked ports."  The wording in the
section
is a bit misleading - it's not the SDP attribute that fixes the issue,
it's
the fact that one sends something out on the RTCP port and thus creates
a
NAT binding, and the attribute just tells the other end what that
binding
resulted in so they can send RTCP to that port.  But that's not my real
concern - I think we should (instead?) be advocating the RTP/RTCP port
muxing draft from AVT (draft-ietf-avt-rtp-and-rtcp-mux-07.txt) currently
in
the RFC editor's queue.  

[Chris Boulton] Agreed.  I will expand the text in the next version (not
sure if it should be 'instead').

Section 3.2.3 says "A TURN service will almost always provide media
traffic
to a SIP entity but it is RECOMMENDED that this method only be used as a
last resort and not as a general mechanism for NAT traversal."  I think
this
may be a bit confusing.  If I recall right, ICE recommended the UAC to
always get TURN-derived addresses for the initial ICE offer, because it
had
the highest chance of success.  In fact I thought that was the address
used
in the m= line to begin with, just in case the far-end UAS did not
support
ICE.  It would be set at a low priority, though, I think.  But the point
is
a TURN address should be allocated, but only used if the other ICE
connectivity checks fail. (or if local policy tells you to prefer it)

[Chris Boulton] I will clarify text.

Section 3.2.5 "Solution Profiles".  I think this section should be
removed
entirely.  This just looks like marketing labels to me.  I don't
understand
what value they have from a BCP or RFC perspective.  This isn't meant to
be
a PICS proforma, is it?

[Chris Boulton] I will let Jonathan R comment on this as it was
originally his concept.  I actually think that the profiles provide a
useful BCP style set of information. 

Section 4, the scenarios.  This is a bit of a nit, but I think all of
the
example messages should use an IP Address in the contact URI and Via.  I
don't think I have ever seen an FQDN in a contact.  And for NAT
traversal
examples in particular, that's one of those differences that make it
"unique" from non-NAT call flow scenarios.

[Chris Boulton] I will take a look.

[Chris Boulton] Agreed.

Section 5.2 says to use ANAT for IPv4-IPv6.  I believe ANAT was
denounced at
the Prague IETF and ICE must be used instead.  This section needs to be
re-done to show ICE usage instead.

[Chris Boulton] Already been spotted in another review and on the list
for change.

Overall - the words "connection reuse" are used when you really mean
Outbound (connection-reuse is a different draft).  For example
"Connection
Re-use Tuple" throughout section 4, and it's even described as the
"Connection Re-use draft" in 4.1.1.2.

[Chris Boulton] Agreed.

-hadriel

Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Ubiquity Software Corporation plc, a company registered under the laws of England and Wales, Registration 2719723, registered offices at Eastern Business Park, Building 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom.