Hi Patrick, Hi Greg, as you know, the aspects of NAT have definitely not been considered on the development of SIP (RFC 3261); so this topic has unfortunately much room for discussions how to handle problematical issues in detail. In fact, using SIP together with NAT is still a tricky pain requiring uncomely workarounds (STUN, keepalive, ...) from the user side. Nf_conntrack_sip has helped to reduce the issues of SIP with NAT a lot from the user side; but beyond doubt there are still open traps and unsolved Bugs requiring some review on the code in some cases. :-/ Patrick McHardy wrote: > Greg Alexander wrote: > > Is there anyone else on this mailing list who cares to chime in? > > I guess almost everyone on this list does not suffer from this problem regarding no need for this code on the own "home" installation. > > I believe it is more important to conform to standards and common > > practice, especially since they are the same in this case and > > present no undue burden or risk. > > Nf_conntrack_sip should conform to the standards as far as possible; but on the other side - as it's enabled by default on many distros - it's required not to open potential security holes on a default installation. > > Patrick McHardy seems to believe it is more important to enforce a > > rule of thumb prohibiting wildcard expectations. > > > > We each have precedent in other NAT helpers to support our position. > > Well, I'll add one final point. You mentioned the IRC helper > as precedent, without referring to anything concrete. You're > mistaken though, the destination address is fixed. But I see > where your misunderstanding might come from. > > What the SIP helper does is allow expectations between *arbitrary* > hosts when the direct_media option is off - the destination address > originates from the SDP payload, the source address is a wildcard. > IMHO the available options should be documented with examples requiring a change of the default parameters. Unfortunately using the default settings results in for most users hardly to debug problems in some cases. > > Any other opinions? Linux is a group effort. > > > > [...] > > Have fun. sure: Yes, we have ;) -Florian -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
