Hi All.

I don't know if I'm going to be of any help here as I've mentioned before that I'm as dumb as a door knob when it comes to the network and/or clustering stuff.

Our underlying network (ie, BGP pipes, routers, firewalls, LVS, MySQL clusters, SIP clusters, Asterisk clusters, NFS storage, etc, etc) have been implemented by the engineers we hired from Red Hat.

These guys have implmented (AFAIK) our network layer the same way Google has done their WWW farm(s). They have intimate knowledge of Google's internal infrastucture because they worked between Red Hat and Google for about 6 years.

All I know is that it has taken about 4 months of work to get things stable. We understand that a VoIP platform isn't about the softswitch - but rather the network. I've asked on more than one occasion if I could release our network configuration to serusers and the answer has always been "no", so there's not much I can contribute here.

The ser source files are another story. We fully shared our ser.cfg, tcp/udp network patch, usrloc patch, etc - but that doesn't help with this.

The only bright point I can offer here is that I'm 100% certain that the LVS source code has __not__ been modified.

Sorry,
Paul

On Apr 11, 2005 4:46 AM, Greger V. Teigre <greger@teigre.com> wrote:
After my last email, I looked at ktcpvs and realized I ignored a couple of things: ktcpvs only supports tcp (http is obviously tcp-based, but I thought it supported udp for other protocols).  I don't know how much work implementing udp would be.
    Here is a discussion of SIP and LVS that I found useful (though not encouraging).
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.services_that_dont_work_yet.html
 
Paul: I'm starting to get really curious on the standard LVS components used for your stickiness!  I'm not aware (also after searching now) of an LVS balancing mechanism that allows correct stickness on SIP udp...!
And I found other too who are looking for it:
http://archive.linuxvirtualserver.org/html/lvs-users/2005-02/msg00251.html
 
My understanding is that ipvs must be extended (according to the developer) with a call-id based scheduler and that this work has several people willing to fund development, but that this has not(?) started yet.  The problem is that ipvs is based on ip header analysis and extending the hashing algorithms to also include payload-based analysis is not straight-forward.
g-)