Re: [Serusers] FCP support in SER

At 10:16 PM 1/9/2003, Nils Ohlmeier wrote: That's true unfortunately :-) Let me start from the simplest case: firewalls. That is easier because you do not need to mangle SIP requests. In firewall scenarios, you just create a new module, link it with transaction module using callbacks (those that are triggered on transaction completion), and when callbacks occur, you open up or close pinholes. Design issues: - for efficency reasons, it is beneficial to open persistent connections to the FCP server. Like in usrloc module each child process opens up an SQL connection, each ser child in fcp-client module would have to open up an FCP connection (they cannot share a single TCP connection). - there is a question of time validity of the rules. Clearly, keeping call state to be able to send rule keep-alives to fcpd is not very efficient. I think the right way is to use session-timer -- that makes UAs to send "SIP keep-alives" which are then translated into FCP keep-alives by ser. Call state is kept only in end-devices and propagated through proxy to firewall. It however assumes session-timer support. Quite some phones do it today, quite few get it right. Well -- perhaps we can afford throwing users of phones with missing or broken session-timer support over board? - early media -- if media is sent before INVITE completes, the FCP modules should bind itself to some other callbacks too and watch for early-media situations - media sources -- with SIP, noone really knows from where media comes. The rules thus look should permit any sender for a give destination. If one wished to have a more restrictive policy, one could use heurisitcs, and assume that other party's IP address in Contact is from where media will be coming. NATs are even worse -- digest firewalls first :-) -Jiri