Hi All.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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 &quot;no&quot;, so there's not much I can contribute here. <br>
<br>
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.<br>
<br>
The only bright point I can offer here is that I'm 100% certain that the LVS source code has __not__ been modified.<br>
<br>
Sorry,<br>
Paul<br><br><div><span class="gmail_quote">On Apr 11, 2005 4:46 AM, <b class="gmail_sendername">Greger V. Teigre</b> &lt;<a href="mailto:greger@teigre.com">greger@teigre.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">






<div>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).&nbsp; I don't know how much work 
implementing udp would be.</div>
<div>&nbsp;&nbsp;&nbsp; Here is a discussion of SIP and LVS that I found useful 
(though not encouraging).</div>
<div><a href="http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.services_that_dont_work_yet.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.services_that_dont_work_yet.html</a></div>
<div>&nbsp;</div>
<div>Paul: I'm starting to get really curious on the standard LVS components 
used for your stickiness!&nbsp; I'm not aware (also after searching now) of an 
LVS balancing mechanism that allows correct stickness on SIP udp...!</div>
<div>And I found other too who are looking for it:</div>
<div><a href="http://archive.linuxvirtualserver.org/html/lvs-users/2005-02/msg00251.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://archive.linuxvirtualserver.org/html/lvs-users/2005-02/msg00251.html</a></div>
<div>&nbsp;</div>
<div>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.&nbsp; 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. </div>
<div>g-)</div>
<div>&nbsp;</div></blockquote></div><br>