On Sunday 07 April 2002 10:51, Harald Welte wrote: > The 'official' IETF approach on how to NAT SIP/SDP is that you have to > run some SIP proxy, which communicates the to-be-opened port and NAT > mappings over some protocol (formerly FCP, firewall configuration protocol) > to the firewall. > > As this seems to be a broader task, the IETF has formed the MIDCOM working > group, and FCP has been abandoned.
As one of the authors of FCP and it's deamon i would like to comment Haralds introduction: FCP is our own creation, because of the lack of an 'offical' protocol from the IETF. It was and probaly will never become an offical IETF protocl. The basic idea behind the FCPd is for complex protocol like SIP/SDP not to tranfer the protocol knowledge into contrack module. Leave the knowledge in the applications (proxys or server) and let them decide which user, apllication or host is allowed to request for 'holes' in the firewall for an amount of time. The FCP and the deamon should be seens as proof of concept implementation from our research institut (http://www.fokus.fhg.de). I woludn't say that it's abondoned, but that maybe depends on the point of view. > Result: There is no well-defined clean method of SIP firewall/NAT > traversal yet - and it will definitely take some more IETF drafts until > MIDCOM will publish some standards. Right. > Please also see that SIP call scenarios can be farly complex. Signalling > is regularly taking a different path than data packets. There's an > IETF draft about 'example SIP call scenarios', which is about 260 pages. > > So in the end this is quite a bit of work, and can not be easily compared > with any of the existing conntrack/nat helpers. Very correct. > There also need to be a few netfilter API changes in order to support SIP. > Stuff like port reservations. And it also needs port reservations for > two consecutive port numbers. Or in the case you have audio and video, > four consecutive numbers, ... Okay port reservation is done by our deamon by simply binding a socket. We know that this is nasty but it is the easiest way to get shure that the ports we use in NAT rules are not used by netfilter or an application on the firewall. Regards Nils Ohlmeier