Re: [MMUSIC] Continued WG interest inSDP offer/answerwithmiddleboxes?

[Hadriel Kaplan <[e-mail]>]

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