godson.in

If you have ever used Asterisk's AMI (Asterisk Manager Interface ). You will know the pain of tracking a particular channel, especially when its getting originated or being bridged with some other channel. There is no easy way to do that cause in asterisk the Unique ID of a channel keeps changing over its life span. New Unique IDs are created through out a channel's lifespan when originated one Unique ID and when linked with other channel again a new Unique ID etc etc. All this gives jitters to programmer, and this kind of behaviour clearly shows some design mistakes in Asterisk.


Asterisk uses unix timestamp appended by an incremental counter as a channel's uniqueid.

A sample unique id of a channel used by asterisk - 1268129694.0

This post is not about talking down Asterisk or any thing. Asterisk is a great milestone in opensource telephony evolution.

That brings us to next beast in the evolution FreeSWITCH. FreeSWITCH is built by a person (Anthony Minessale II ) who has great understanding of Asterisk. So, he made sure that the short comings of Asterisk are addressed in a proper way. EventSocket interface of FreeSWITCH is more powerful and hooks into almost every aspect of FreeSWITCH. EventSocket is one single protocol for call control and switch control instead of two different protocols that Asterisk has FastAGI and AMI.

FreeSWITCH tracks calls in a real neat way by hooking them up with UUIDs. Each leg or channel in FreeSWITCH is identified by a single UUID through out its lifespan. Which makes it a breeze for the programmer to deal with call events and control the calls. FreeSWITCH also allows you to specify your own UUID for a call leg while originating, that way you are given absolute control of what goes on with a leg.

Before I end the post, here is a sample unique id of a channel used by FreeSWITCH - 60a3c6de-dc73-11df-9c62-00238b1dd454

Managing sessions in xmlrpclib client in the python standard library is not supported. If you are using xmlrpclib for serious work,sooner or later you are going to face this issue of managing authenticated sessions. Inspecting xmlrpclib.py reveals that it does all its HTTP communication using Transport class defined in xmlrpclib.py (Be ware that the current trunk version Transport is different from the one shipped with Python 2.5) The following code is implemented to work with Python2.5 version of xmlrpclib.

You can get a clear description of HTTP session mechanics from the wikipedia page . So to implement this in python2.5's xmlrpc client you need to subclass and override certain methods of Transport class as shown below.



class SessionTransport(Transport):
def __init__(self):
Transport.__init__(self, use_datetime=0)

#def request(self, r):pass
session = ''
def request(self, host, handler, request_body, verbose=0):

# issue XML-RPC request

h = self.make_connection(host)
if verbose:
h.set_debuglevel(1)

self.send_request(h, handler, request_body)
self.send_host(h, host)
self.send_user_agent(h)
self.send_content(h, request_body)

errcode, errmsg, headers = h.getreply()

self.session = headers.getheader("Set-Cookie", "").split(";")[0]



if errcode != 200:
raise ProtocolError(
host + handler,
errcode, errmsg,
headers
)

self.verbose = verbose

try:
sock = h._conn.sock
except AttributeError:
sock = None

return self._parse_response(h.getfile(), sock)


def send_user_agent(self, connection):

if self.session:
connection.putheader("Cookie",self.session)
return Transport.send_user_agent(self, connection)
Now, you just need to pass the instance of SessionTransport to xmlrpclib.ServerProxy 's transport argument. I was using Twisted XML-RPC server on server side. When you create a session in twisted using request.getSession it will send the Set-Cookie: TWISTED_SESSION:231123125usd ; Path=/ to client in HTTP headers. All that above code does, is to extract that Set-Cookie value and set it back in Cookie header on each subsequent request to server. This is fairly simple and should work with any other HTTP server.

There are some decent modules out there that help us in tying up FreeSWITCH with Radius namely mod_rad_auth and mod_radius_cdr. However, they are pretty much limited and lack some of main features like dynamic routing that some radius servers can provide. Integrating FreeSWITCH with such radius server which can do routing and billing logic will allow us to deploy FreeSWITCH on a large scale, ideal for whole sale carriers kind of thing.

This integration will give us the luxury of not having to configure any endpoint details that FreeSWITCH has to send calls to. We will have one centralized billing server which talks radius protocol. And NAS (name is debatable ) talking to many FreeSWITCH instances. The following image makes it clear.

Now the challenge is to implement NAS that does the conversion of radius protocol to a language that FreeSWITCH understands. Luckily FreeSWITCH comes with numerous features and tools that offer hooks into every place of FreeSWTICH. I've implemented this NAS in python using Twisted's higly scalable network architecture. The major pain is understanding the cisco's radius dictionary attributes and how exactly they map to the FreeSWITCH variables. I've implemented all the important features of what VoIP radius protocol has to offer.

• Endpioint Authorization (Digest and IP)
• Route Autthorization (for Dynamic routing, limit call duration based on balance amount)
• Accouting Requests (Radius CDR for billing )