Re: [MMUSIC] Continued WG interest inSDPoffer/answerwithmiddleboxes?

["Muthu ArulMozhi Perumal (mperumal)" <[e-mail]>]

|When you say "to aid in firewall/NAT traversal", I assume 
|you mean when the SIP+middlebox device *is* the firewall/NAT, 
|right?  You do NOT mean when a SIP+middlebox device is out in 
|the network, helping the UA traverse a Firewall/NAT in-between 
|it and the UA? (what is normally called "Hosted NAT Traversal" 
|or "Far-end NAT traversal" by vendors)

Yes, primarily the former use-case. However, the draft also described
the later (see section 5).

|I ask because the former case of being the NAT is not the same
|as the latter case.  Latching and most of the policies described
|in this draft do not typically apply to the former case, but do 
|to the latter.

The draft does make this clear in section 5.1:

<snip>
If the middlebox supports the traversal of residential NATs, it applies
a technique called "media latching": The destination IP address of
packets forwarded by the middlebox in the outbound direction is derived
from the source IP address of packets received in the inbound direction.
This overrides a destination address possibly configured by the MIDCOM
agent.
</snip>

Overall, IMHO the recommendations in the draft seem useful to the kind
of architecture/problems it describes. However, whether it applies to
current deployments is something I am not sure. The draft claims such
middleboxes are for instance the TISPAN A-BGF/C-BGF/I-BGF and the 3GPP
IMS Access Gateway..perhaps this was long ago?

Muthu

|-----Original Message-----
|From: Hadriel Kaplan [mailto:[e-mail]]
|Sent: Friday, April 01, 2011 5:46 PM
|To: Muthu ArulMozhi Perumal (mperumal)
|Cc: mmusic
|Subject: Re: [MMUSIC] Continued WG interest
inSDPoffer/answerwithmiddleboxes?
|
|
|On Mar 31, 2011, at 10:48 PM, Muthu ArulMozhi Perumal (mperumal) wrote:
|
|> The main goal of the draft as it seems to claim is to describe the
|> desirable behaviors of middleboxes and signaling protocols that
operate
|> on the media path, to aid in firewall/NAT traversal. It looks like an
|> extension of RFC 3303 whose focus is also firewall and NAT traversal
|> use-cases. The draft claims that the architecture/functions it
describes
|> is used in IMS and specified in 3GPP, TISPAN and PacketCable specs --
if
|> it true, then this is where the recommendations in the draft would be
|> useful I think.
|
|When you say "to aid in firewall/NAT traversal", I assume you mean when
the SIP+middlebox device *is*
|the firewall/NAT, right?  You do NOT mean when a SIP+middlebox device
is out in the network, helping
|the UA traverse a Firewall/NAT in-between it and the UA? (what is
normally called "Hosted NAT
|Traversal" or "Far-end NAT traversal" by vendors)
|
|I ask because the former case of being the NAT is not the same as the
latter case.  Latching and most
|of the policies described in this draft do not typically apply to the
former case, but do to the
|latter.  ICE behaves differently for the two cases.  SBCs, as well as
the 3GPP and TISPAN variants,
|are of the latter variety, not the former.  And they don't need an RFC
to tell them anything, because
|it's not something they don't already know.  What's worse, it's
actually wrong or misleading in some
|of its recommendations.
|
|The draft conflates the two cases, probably because RFC 3303 did as
well because it is a really old
|RFC from back when the whole SIP middlebox market began.  And the draft
is wrong about ICE because it
|was written before ICE was published.  "Extending" 3303 with this draft
is useless at best, or harmful
|at worst, unless it gets a serious re-write.  My 2 cents anyway.
|
|-hadriel