26 Jan
2005
26 Jan
'05
12:32 p.m.
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