[Serdev] Concept for a SIP cluster implementation

[Greger V. Teigre]

Hi Andreas!
Thanks for a well thought-out and easy-to-read post :-)  I couple of 
comments:
- You refer to EP1 and EP2 and then P1 and P2. I assume these are the same, 
but referring to two different functions?  Anyway, it's a bit confusing
- The path module is still in the experimental cvs module and thus can still 
be changed/expanded etc.  AFAIK, Path can be used to implement several 
functionalities, but is basically the same mechanism. I hope it is possible 
to modify the path module to work well with also your scenario.  I encourage 
the path maintainer, Fermin Galan Marquez, and you to work together on this
- From my point of view, I cannot see any reasons for why this shouldn't be 
possible to include in HEAD once it has proven its stability in experimental
g-)

Andreas Granig wrote:
> Hi,
>
> I'm planning to use SER proxies as SIP load balancers in front of a
> SER cluster, and I'd like to describe the concept here. Comments are
> highly welcome.
>
> The scenario uses two load balancing proxies called Edge Proxies (EP),
> and a SER cluster with multiple registrars and proxies, called REG[]
> here, which stores all contacts into a common DB (a mysql cluster).
>
> A REGISTER would for example be routed like this:
>
> UA1 ---> EP1 ---> REG[x] ---> DB
> UA2 ---> EP2 ---> REG[y] ---> DB
>
> Using the cacheless usrloc module, no SIP replication is done between
> the registrars in the cluster, but it could also be used with the
> standard usrloc module in combination with SIP replication (I will
> implement it for both modules for compatibility reasons).
>
> The proxies EP1 and EP2 are responsible for NAT pinging the UAs which
> registered via them. As a first step they will ping each UA no matter
> if it really registered via them, but for performance reasons this
> could be tuned to only ping the relevant UAs (will be done in a
> second step).
> To make sure that subsequent requests towards the UAs are routed via
> the correct proxy (P1 or P2) for proper NAT traversal, I want to use
> the Path header, so an INVITE for the above scenario could look like
> this:
> UA1 ---> EP1 ---> REG[z] ---> EP2 ---> UA2
>
> The current path module implementation has quite some shortcomings,
> and don't really like the logical design, so my idea is to implement
> it in such a way:
>
> P1 and P2 add themselves to the Path header of the REGISTER using a
> function add_to_path() (names of the functions are for just examples
> btw, and as a first step the Path header could even be added with
> append_hf()).
>
> REG[] calls save("location"), and the Path vector is stored along with
> the contacts in the location table. Since a UA could register some
> contacts via P1 and some others via P2, there could be different Path
> vectors for an AOR, so a proper branch handling has to be done.
>
> Now if UA1 calls UA2 like in the example above, lookup("location")
> fetches the contacts and stores the Path vector for each branch in
> AVPs. Before calling t_relay(), a branch_route is registered if Path
> vectors are available, and in this branch route the corresponding
> Path vector loaded from AVP is added to the Route set:
>
>   route[x] {
>     ...
>     if(has_path()) {
>       t_on_branch("1");
>     }
>     ...
>     t_relay();
>   }
>
>   branch_route[1] {
>     path_route();
>   }
>
> So what do you think about this approach? Is this a passable solution,
> and would there be any chance to get the changes into HEAD when
> finished?
> Looking forward for comments,
> Andy
>
> _______________________________________________
> Serdev mailing list
> serdev at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev