[Serusers] FCP support in SER

Jiri Kuthan jiri at iptel.org
Thu Jan 9 23:50:51 CET 2003


At 10:16 PM 1/9/2003, Nils Ohlmeier wrote:
>For questions about where and how to intercept and change the messages in the 
>transaction management of SER Jiri is your man. 

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 




More information about the sr-users mailing list