|
Over the past few weeks I've been researching what would be involved
in making a UDP based SIP aware module for LVS/IPVS. Thank you to
those I've contacted directly and for the help and insight you've
provided up to this point. Conceptually this doesn't seem like a
difficult component to add but I am currently not familiar enough with
the ipvs code to undertake writing such a module.
What follows is my understanding of how such a module would work. I
could be totally mistaken in my methodology so my intent is to start a
discussion and have everyone weigh in on what should be done in order
to design such a module.
Since the most common implementation of SIP utilizes UDP I will
concentrate on this scenario at present. I'm also assuming that the
resultant RTP streams will not be handled by ipvs and the SIP ipvs
module will only handle SIP signaling. There currently exist other
means of load balancing or scheduling RTP streams to multiple RTP
proxy servers in products such as SER provided the LVS setup is not
using NAT. Perhaps we could tackle TCP based SIP and the RTP streams
at a later time but for a first pass, I propose we focus solely on the
UDP SIP signaling portion.
As ipvs is currently connection based, which is not what is needed by
UDP SIP, as UDP is a stateless protocol and connections can't be used
to make decisions to route SIP packets. Any decisions on how to route
SIP packets to realservers behind a director node would have to be
made based on the unique Call-ID field contained within the SIP
header, constituting a degree of layer 7 switching.
My understanding is that ip_vs_conn currently hashes based upon
IP/port. I propose we either write another module similar to
ip_vs_conn, maybe ip_vs_lookup, which will handle hashing the SIP
Call-ID or modify ip_vs_conn to also accept other parameters like
Call-ID instead of IP/port information.
On top of this, we would need a module to handle the SIP requests
themselves, perhaps an application helper similar to ip_vs_ftp in
order to listen for inbound and outbound requests. This module would
then parse out the SIP Call-ID and utilize ip_vs_lookup in a similar
fashion to ip_vs_conn to determine if this is a new Call-ID or an
existing one and then route it to a realserver based on the load
balancing or scheduling provided by other ipvs modules as is done
normally for all other ipvs configured services.
As I mentioned, I'm not familiar with all of the internals of ipvs but
this approach seems logical to me. Hopefully those more familiar with
ipvs can point out where my proposed implementation would not work and
suggest ways to work around any issues that are encountered.
If we can come up with a workable design for this SIP module and
someone is willing to code the module(s), I am willing to financially
sponsor its development through a contract programming job, the
details of which can be negotiated at a later time. The module(s)
would, of course, be contributed back to the LVS project upon
completion.
I look forward to hearing the list's feedback and moving forward on
implementing this module as I believe that this capability would be of
great benefit to the LVS project.
Cheers,
-Curt
|
