[Serusers] Carrier-grade framework for SER

[Andreas Granig]

Juha Heinanen wrote:
> is replication of register requests to other sers too slow for you?

With t_replicate() only two SERs can replicate back and forth, and with 
stateless forward()ing packets may get lost because of missing 
retransmission.
Beside that the domain tables (location etc) get out of synch if one of 
the SERs is down for a moment, because retransmission is only tried a 
few times.

Or is somebody aware of other possibilities for replication?

> regarding aliases, i don't use aliases table at all.  i return the
> possible aliases called user as reply items to radius_does_uri_exist
> call.

I use different domains for call forwarding, like cfuc for call forward 
unconditional, cfb for call forward on busy and so on:

In main route I have a routing logic like this
if(lookup("cfuc")) { /* cfuc active */ }
if(lookup("location") { /* a voip call */ }
else { /* a pstn call */ }
t_relay();

and in a failure route for example:
if(t_check_status("486") && lookup("cfb"))
{/*call forward on busy, relay*/}

So I register call forwarding destinations like aliases, like:
serctl cfuc add <real-user-name> sip:<forwarded-uri>

These domains also have to be replicated among the SERs like the 
location domain.

> this is close to what i did when i wrote fifo server.  separate fifo
> server was supposed to be a temporary thing that can go away when ser
> learns to receive fifo commands over tcp.  i still think that it is a
> bad idea to introduce a new process to the system that can go down
> requiring queuing and other complexities.  so why just not introduce tcp
> support for ser fifo?

Queueing has to be done anyway, because if one SER is down for, say, ten 
minutes, the registrations received in that time on other SERs have to 
be replicated to that SER.

So you could do the queueing in a SER replication module, or just pass 
the modified contacts to an external application that handles this.
If the external application isn't reachable, the module could write the 
contact messages to a DB table instead, which is read by the application 
periodically.

Andy