[Serusers] Carrier-grade framework for SER

Andreas Granig andreas.granig at inode.info
Thu Feb 10 11:09:21 CET 2005


Hi Greger,

> Any conclusions or progress you have made after the discussion on the 
> mailing list?  I learned a few things :-) Tried to summarize my 
> understanding of the different issues and how I understood the 
> "recommended" approach, but didn't see any response from you.

There was a lot that had to be done in the meanwhile, sorry ;o)

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.

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.

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)

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.

Cheers,
Andy




More information about the sr-users mailing list