[Serusers] Carrier-grade framework for SER

[Greger V. Teigre]

Hi Andreas,
Thank you for sharing your setup with the list! It is one more of several 
interesting reference designs/implementations that would be very useful to 
index and provide access to from the iptel.org site.  I don't know who 
controls the iptel.org website?  It could be as simple as a FAQ page where 
each FAQ item is a link to a specific post on mail.iptel.org (to keep the 
work down). I'm sure many basic questions on the list could be avoided with 
such a FAQ page.

See inline comments.

> But here's my current (not perfect but perfectly working) solution:
>
> Locations are replicated on SIP-layer using forward_tcp(...) (thanks
> to Juha for the hint) on one side and save_noreply(...) on the other
> side. This works very reliable with three SERs although it wouldn't
> scale much, so this has to be improved in the future.
>
> The config looks like:
>
>   if(method == "REGISTER")
>   {
>     if(src_ip==<IP of peer1> || src_ip==<IP of peer2>)
>     {
>       save_noreply("location");
>     }
>     else
>     {
>       if(!www_authorize("<my domain>", "subscriber"))
>       {
>         www_challenge("<my domain>", "0");
>         break;
>       }
>       if(!check_to())
>       {
>         sl_send_reply("403", "Use To=username next time");
>         break;
>       }
>       if(!save("location")) { sl_reply_error(); break; }
>       forward_tcp("<IP of peer1", 5060);
>       forward_tcp("<IP of peer2", 5060);
>     }
>     break;
>   }
>
> The usrloc modules operates in write-through-mode so locations are
> always synched to the db.

I think the above is a good description of a simple, but generic replication 
setup.

> When a SER goes down, I've a script for recovering the location
> tables, and it looks like:
>
>   mysqldump -h${SER_PEER} -u${DB_RUSER} -p${DB_RPASS} -Q \
>       --extended-insert --add-drop-table ser ${SER_LOCATIONS} \
>       | mysql -u${DB_LUSER} -p${DB_LPASS} ser
>   /usr/local/ser/sbin/ser.sh start
>
> where $SER_LOCATIONS holds the location tables like "location",
> "aliases" and so on.

If I understand you correctly, you dump on one server (one that is up) and 
load on the one that was down?  Is this an automatic operation?

> What still has to be done is replicating the nonce value so UAs with
> DNS-SRV implementations which change the server on each request and
> SERs behind load balancers will work too.
>
> It's not as nifty as using diameter or something like that but it
> grants me some reprieve ;o)

Yes, this is where a DB setup gets complicated.  However, maybe you could to 
reduce the time for the nonce to go stale?  There is a variable for setting 
that value, I think the default is 300 seconds. The result would be many 
more authentications. I'm not completely sure how this works for sql, as we 
only use RADIUS auths, but I would imagine a new request to a new server 
where the nonce is wrong would result in a new auth? Or is the response a 
NAK and that's why you need replication?
    It seems to me that the messages in a single authentication (REGISTER, 
auth required, new REGISTER, ok) should go to the same server regardless of 
UA SRV implementation  The next auth will be an INVITE probably and the 
nonce will probably be stale (300 secs) and result in a new auth.  Also, a 
load balancer should (with reference to previous serusers discussions) 
probably make sure that all messages from one UA goes to the same server. 
At least is that true for an application level balancer, so that NAT 
problems are handled correctly.  If the load balancer is a TCP/IP-level 
balancer, you should probably distribute on src_ip and thus avoid your nonce 
problem.

    Sorry if this is not relevant to SQL auths... ;-)

> For distributing FIFO commands to provision call forwards and read
> SER's status etc I wrote an XML-RPC server which communicates with
> SER's unixsocket-FIFO-interface. So a simple PHP script communicating
> with a SER looks like this:
>
>   $url = "http://my.server:5080/xmlrpc";
>   $method = "fifo.execute";
>   $fifocmd = "ul_show_contact";
>   $fifoparams = array("location", "012345");
>
>   $ar = array("cmdname"=>$fifocmd,"cmdparams"=>$fifoparams);
>   $request = xmlrpc_encode_request($method, $ar);
>
>   $ch = curl_init();
>   curl_setopt($ch, CURLOPT_URL, $url);
>   curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
>   curl_setopt($ch, CURLOPT_POST, 1);
>   curl_setopt($ch, CURLOPT_POSTFIELDS, $request);
>
>   $response = curl_exec($ch);
>   $xmlar = xmlrpc_decode($response);
>   if(xmlrpc_is_fault($xmlar))
>   { /* fault processing, print the error */ }
>   else
>   { /* normal processing, print the response parameters etc */ }
>
> The XML-RPC solution seems to be more flexible to me than the
> TCP-interface for SER because it can not only execute FIFO commands
> but can easily be extended to communicate with the mediaproxy for
> example. But this opinion may depend on one's needs.
>
> The licensing question of the XML-RPC server is still not clear
> (chiefs, you know), but I hope I get it licensed as GPL.

I agree with you, a pure TCP-interface is too low-level.  I also agree with 
Juha in that an XML-RPC/SOAP implementation should be done as an extension 
to the current unix socket interface and be an integrated part of ser.  Have 
you coded it in C?  If so, maybe the code be used as a starting point 
(dependent on GPL from your chiefs)?

g-)