<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v =
"urn:schemas-microsoft-com:vml" xmlns:o =
"urn:schemas-microsoft-com:office:office" xmlns:w =
"urn:schemas-microsoft-com:office:word"><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content=Word.Document name=ProgId>
<META content="MSHTML 6.00.2900.2604" name=GENERATOR>
<META content="Microsoft Word 11" name=Originator><LINK
href="cid:filelist.xml@01C53F59.F4FDCC40" rel=File-List><LINK
href="cid:editdata.mso" rel=Edit-Time-Data><!--[if !mso]>
<STYLE>v\:* {
BEHAVIOR: url(#default#VML)
}
o\:* {
BEHAVIOR: url(#default#VML)
}
w\:* {
BEHAVIOR: url(#default#VML)
}
.shape {
BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><!--[if gte mso 9]><xml>
<o:OfficeDocumentSettings>
<o:DoNotRelyOnCSS/>
</o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:WordDocument>
<w:SpellingState>Clean</w:SpellingState>
<w:GrammarState>Clean</w:GrammarState>
<w:DocumentKind>DocumentEmail</w:DocumentKind>
<w:EnvelopeVis/>
<w:ValidateAgainstSchemas/>
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
<w:IgnoreMixedContent>false</w:IgnoreMixedContent>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
<w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
</w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:LatentStyles DefLockedState="false" LatentStyleCount="156">
</w:LatentStyles>
</xml><![endif]-->
<STYLE>
<!--
/* Font Definitions */
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;
mso-font-charset:0;
mso-generic-font-family:swiss;
mso-font-pitch:variable;
mso-font-signature:1627421319 -2147483648 8 0 66047 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-parent:"";
margin:0in;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:"Times New Roman";
mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;
text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
{color:blue;
text-decoration:underline;
text-underline:single;}
span.EmailStyle17
{mso-style-type:personal;
mso-style-noshow:yes;
mso-ansi-font-size:10.0pt;
mso-bidi-font-size:10.0pt;
font-family:Arial;
mso-ascii-font-family:Arial;
mso-hansi-font-family:Arial;
mso-bidi-font-family:Arial;
color:navy;}
span.EmailStyle18
{mso-style-type:personal-reply;
mso-style-noshow:yes;
mso-ansi-font-size:10.0pt;
mso-bidi-font-size:10.0pt;
font-family:Arial;
mso-ascii-font-family:Arial;
mso-hansi-font-family:Arial;
mso-bidi-font-family:Arial;
color:navy;}
span.SpellE
{mso-style-name:"";
mso-spl-e:yes;}
span.GramE
{mso-style-name:"";
mso-gram-e:yes;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;
mso-header-margin:.5in;
mso-footer-margin:.5in;
mso-paper-source:0;}
div.Section1
{page:Section1;}
-->
</STYLE>
<!--[if gte mso 10]>
<style>
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:"Times New Roman";
mso-ansi-language:#0400;
mso-fareast-language:#0400;
mso-bidi-language:#0400;}
</style>
<![endif]--><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=EN-US style="tab-interval: .5in" vLink=blue link=blue bgColor=white>
<DIV>I agree that NAT should be resolved by the peers. I haven't looked at the
forking proxy details; I assume it will do sort of a redirect for REGISTERs and
INVITEs, so that everything thereafter is handled by each SIP server. I
still cannot really see how you solve the NAT problem,though. The public IP of
the SIP server handling the first REGISTER will be the only IP allowed to send
an INVITE to the UA, so if another UA registered with another server makes a
call, the SIP forking proxy must make sure that the INVITE is sent through the
SIP server having done the initial registration of callee. </DIV>
<DIV>g-)</DIV>
<DIV> </DIV>
<DIV>---- Original Message ----<BR>From: Alex Vishnev<BR>To: 'Greger V. Teigre'
; serusers@lists.iptel.org<BR>Sent: Tuesday, April 12, 2005 06:20 PM<BR>Subject: RE:
LVS, load balancing,and stickness was ==> Re: [Serusers]<BR>moreusrloc
synchronization <BR><BR>> Greger,<BR>> <BR>> I am not an expert on
anycast as well. I just know it exists and<BR>> people are starting to look
at it more seriously for HA option. That<BR>> is why I though DNS SRV records
would be an easier solution.<BR>> Regarding your comments on NAT, I don’t
believe it is an issue as it<BR>> relates to forking proxy. Forking proxy
should not resolve NAT, it is<BR>> a job for its peers. As for configuring
SER as forking proxy, I<BR>> thought I read about it a while back, but now I
can’t seem to locate<BR>> it. I hope I was not dreaming
;-). <BR>> <BR>> In any case, I will
continue to google around to see if SER has this<BR>> option. <BR>>
<BR>> Sincerely,<BR>> <BR>> Alex<BR>> <BR>> <BR>> <BR>>
<BR>> From: Greger V. Teigre [mailto:greger@teigre.com]<BR>> Sent:
Tuesday, April 12, 2005 6:21 AM<BR>> To: Alex Vishnev;
serusers@lists.iptel.org<BR>> Subject: Re: LVS, load balancing,and stickness was
==> Re: [Serusers]<BR>> moreusrloc synchronization <BR>> <BR>>
Alex,<BR>> I'm not really knowledgable enough about anycast to say
anything<BR>> useful. The only is that in your described setup, I
cannot really<BR>> see how you get around the UA behind restricted (or worse)
NAT. <BR>> I have never tried to configure SER
as a forking proxy, but I<BR>> wouldn't be surprised if it was possible.
<BR>> g-)<BR>> <BR>> ---- Original Message ----<BR>> From: Alex
Vishnev<BR>> To: serusers@lists.iptel.org<BR>> Sent: Monday, April 11, 2005
02:30 PM<BR>> Subject: RE: LVS, load balancing, and stickness was ==> Re:
[Serusers]<BR>> moreusrloc synchronization<BR>> <BR>>> Greger and
Paul,<BR>>> <BR>>> I think you understood me correctly regarding
forking proxy. It is<BR>>> the proxy that will fork out the requests to
all available peering<BR>>> proxies. This approach does not require
stickiness based on Call-id.<BR>>> AFAIK, once the forking proxy receives
an acknowledgement from one of<BR>>> its peers, then the rest of the
session will be done directly to that<BR>>> peer without the use of the
forking proxy. I am considering 2<BR>>> approaches to resolve availability
of forking proxy. 1 – using<BR>>> ANYCAST (good high level
article:<BR>>> http://www.kuro5hin.org/story/2003/12/31/173152/86). 2 –
using dns<BR>>> srv. I am still trying to determine if ANYCAST is a good
solution for<BR>>> creating local RPs with forking proxy. However, I think
that dns srv<BR>>> records can easily be implemented to allow simple round
robin between<BR>>> multiple forking proxies. Thoughts?<BR>>>
<BR>>> Alex<BR>>> <BR>>> <BR>>> <BR>>>
<BR>>> From: serusers-bounces@lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org]<BR>>> On Behalf Of Greger V.
Teigre<BR>>> Sent: Monday, April 11, 2005 4:47 AM<BR>>> To:
kramarv@yahoo.com<BR>>> Cc: serusers@lists.iptel.org<BR>>> Subject: LVS,
load balancing, and stickness was ==> Re: [Serusers]<BR>>> more usrloc
synchronization<BR>>> <BR>>> After my last email, I looked at ktcpvs
and realized I ignored a<BR>>> couple of things: ktcpvs only supports tcp
(http is obviously<BR>>> tcp-based, but I thought it supported udp for
other protocols). I<BR>>> don't know how much work implementing udp
would be.<BR>>> Here is a discussion of SIP and
LVS that I found useful (though<BR>>> not encouraging).<BR>>>
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.services_that_dont_work_yet.html<BR>>>
<BR>>> Paul: I'm starting to get really curious on the standard
LVS<BR>>> components used for your stickiness! I'm not aware (also
after<BR>>> searching now) of an LVS balancing mechanism that allows
correct<BR>>> stickness on SIP udp...!<BR>>> And I found other too
who are looking for it:<BR>>>
http://archive.linuxvirtualserver.org/html/lvs-users/2005-02/msg00251.html<BR>>>
<BR>>> My understanding is that ipvs must be extended (according to
the<BR>>> developer) with a call-id based scheduler and that this work
has<BR>>> several people willing to fund development, but that this has
not(?)<BR>>> started yet. The problem is that ipvs is based on ip
header analysis<BR>>> and extending the hashing algorithms to also include
payload-based<BR>>> analysis is not straight-forward.<BR>>>
g-)<BR>>> <BR>>>> With regards to stickiness: Have you looked at
ktcpvs? SIP is an<BR>>>> "http-like" protocol and I'm pretty sure
that you can use the<BR>>>> http-based regex hashing to search for
Call-Id. If you cannot use<BR>>>> it right out of the box, I'm
pretty sure the modifications are<BR>>>>
minimal. The user location problem: With a cluster back-end, I<BR>>>>
also only <BR>>>> see save_memory() as the only option.<BR>>>>
g-)<BR>>>> <BR>>>>> "Greger V. Teigre"
<greger@teigre.com> wrote:<BR>>>>>> Greger, thanks a
lot.<BR>>>>>> The problem with load balancer is that replies goes
to the wrong<BR>>>>>> server due to rewriting outgoing a.b.c.d .
BTW, as Paul pointed,<BR>>>>>> if you define some dummy interface
with Virtual IP (VIP), there<BR>>>>>> is no need to rewrite
outgoing messages (I tested this a little).<BR>>>>>
<BR>>>>> <BR>>>>> Yes, if you use LVS with direct
routing or tunneling, that is what<BR>>>>> you
experience.<BR>>>>> ===Of course. That why I implemented small
"session" stickness.<BR>>>>> However, it causes additional internal
traffic.<BR>>>>> <BR>>>>> What I described was a
"generic" SIP-aware load balancer where SIP<BR>>>>> messages would
be rewritten and stickiness implemented based on ex.<BR>>>>> UA IP
address (or call-id like vovida's load balancer).<BR>>>>> ====Sure,
it's better solution; I think we'll go this way soon (in<BR>>>>> our
next version).<BR>>>>> <BR>>>>>> Why DNS approach is
bad (except restricted NAT - let's say I am<BR>>>>>> solving
this)?<BR>>>>> <BR>>>>> Well, IMO, DNS SRV in itself is
not bad. It's just that many user<BR>>>>> clients do not support DNS
SRV yet. Except that, I like the<BR>>>>> concept and it will
give you a geographical redundancy and load<BR>>>>> balancing. ===I
am trying to build the following architecture:<BR>>>>>
<BR>>>>> DNS (returns domain's public IP)->LVS+tunneling (Virtual
IP)->ser<BR>>>>> clusters (with private IPs)<BR>>>>>
<BR>>>>>> <BR>>>>> <BR>>>>>>
<BR>>>>>
DB<BR>>>>> (MySQL 4.1 cluster)<BR>>>>>
<BR>>>>>> I guess, Paul utilizes load-balancer scenario you have
described.<BR>>>>>> Believe there are only proprietary solutions
for<BR>>>>>> "the-replies-problem". We tried Vovida
call-id-persistence<BR>>>>>> package, unfortunately it didn't
work for us.<BR>>>>> <BR>>>>> Are you referring to the
load balancer proxy? IMHO, the SIP-aware<BR>>>>> load balancer makes
things a bit messy. It sounds to me that the<BR>>>>> LVS +
tunneling/direct routing + virtual IP on dummy adapter is a<BR>>>>>
better solution.<BR>>>>> <BR>>>>>> In my
configuration I use shared remote DB cluster (with<BR>>>>>>
replication). Each ser see it as one-public-IP (exactly
the<BR>>>>>> approach you named for SIP). May be it's good idea
to use local DB<BR>>>>>> clusters, but if you have more than 2
servers your replication<BR>>>>>> algorythm gonna be complex.
Additional problem - it still doesn't<BR>>>>>> solve usrloc
synchronization - you still have to use<BR>>>>>>
t_replicate()...<BR>>>>> <BR>>>>> <BR>>>>>
I'm not sure if I understand.<BR>>>>> ===Oh, probably I expressed
myself not well enough...<BR>>>>> <BR>>>>> So, you have
2 servers at two location, each location with a shared<BR>>>>> DB
and then replication across an IPsec
tunnel??<BR>>>>> IMHO, mysql 3.23.x two-way
replication is quite shaky and<BR>>>>> dangerous to rely on.
With no locking, you will easily get<BR>>>>> overwrites and you have
to be very sure that your application<BR>>>>> doesn't mess up the
DB. I haven't looked at mysql 4.1 clustering,<BR>>>>> but from
the little I have seen, it looks good. Is that what you<BR>>>>>
use?<BR>>>>> <BR>>>>> ===We have 2 or more servers with
MysQL 4.1 virtual server<BR>>>>> (clusters balanced by LVS). We use
MySQL for maintaining<BR>>>>> subscribers' accounts, not for
location. User location is still<BR>>>>> in-memory only so far. I am
afraid I have to switch to ser 09 in<BR>>>>> order to use
save_memory (thanks Paul!) and forward_tcp() for<BR>>>>>
replication. <BR>>>>> <BR>>>>>> With regard to
t_replicate() - it doesn't work for more than 2<BR>>>>>> servers,
so I used exactly forward_tcp() and save_noreply()<BR>>>>>>
(you're absolutely right - this works fine so far); all sers
are<BR>>>>>> happy. Of course, this causes additional traffic.
Interesting<BR>>>>>> whether Paul's FIFO patch reduces traffic
between sers?<BR>>>>> <BR>>>>> I believe Paul uses
forward_tcp() and save_memory() to save the<BR>>>>> location to the
replicated server's memory, while the<BR>>>>> save("location") on
the primary server will store to the DB (which<BR>>>>> then
replicates on the DB level).<BR>>>>> g-)<BR>>>>>
<BR>>>>> <BR>>>>> <BR>>>>>
<BR>>>>> <BR>>>>> Do you Yahoo!?<BR>>>>>
Yahoo! Small Business - Try our new resources site!<BR>>> <BR>>>
<BR>>> <BR>>>
_______________________________________________<BR>>> Serusers mailing
list<BR>>> serusers@lists.iptel.org<BR>>>
http://lists.iptel.org/mailman/listinfo/serusers</DIV></BODY></HTML>