[OpenSIPS-Users] Load Balancer as a Stateless Proxy/Registrar

Bobby Smith bobby.smith at gmail.com
Wed Jun 24 19:12:57 CEST 2009


Looking at some SIP traces of calls, I can see that even with the TM module
enabled and handling requests instead of the SL module, the call-id's are
preserved between handset -> opensips -> appserver.

That's very beneficial, but I know from a performance perspective that
running stateful takes a hit over stateless.  Is there any benefit to try to
wrangle this as a stateless solution, or are the script-like things I'm
going to have to do (interaction with database, saving things to memory)
make it a moot point anyway and I should be taking the easiest road out?

The only thing that grabbed my eye is on the front page, talking about
loadbalancing stateless requests in the neighborhood of 10's of thousands.
That sure caught my eye as a highly desirable attribute ;)





On Wed, Jun 24, 2009 at 12:50 PM, Bobby Smith <bobby.smith at gmail.com> wrote:

> Greetings,
>
> Having some issues with Opensips 1.5, specifically the load balancer and
> dialog modules (and I'm pretty sure they're due to me not understanding
> exactly how they're intended to work).
>
> I want to leave the single opensips server as a stateless device that can
> act as a registrar.  A sip device will register to it, and when a new INVITE
> is processed coming from the sip device, the INVITE will be load balanced to
> a cluster of application servers depending on parameters (similar to the
> asterisk analogy of a conference server, a pstn server, etc etc).
>
> New INVITE requests can come from the application server, which will be
> looked up into the location database and forwarded to the correct registered
> SIP device.
>
> It's highly desirable that we keep the dialog information consistent
> between the application server and the sip devices (for call logging and
> troubleshooting purposes) -- in other words, the application server or sip
> device is responsible for generating call-id, etc etc etc.
>
> Now, here's where my difficulty is coming into play:  When switching to
> using the new load balancing module, if I simply use functions in the SL
> module, there's no dialog.  Obvious, but since the load balancer module
> depends on this to know where to send requests to, what happens is that it
> looks like everything is working correctly, but if we have for example two
> servers in our load balancing pool, ALL requests go to the first server, so
> the second server never gets a request.
>
> If I switch this over to stateful (using the TM module), everything works
> exactly as intended -- a dialog is created, load balancer knows who has
> what, all responses get forwarded accordingly.
>
> So my question is essentially this -- I've read the documentation on the
> website posted about loadbalancer in stateful mode, but is there a way to
> keep track of the information the module needs to load balance calls in
> stateless mode?  I can handle routing all requests through things such as RR
> and loose routing, I just need it to know that the first server already has
> a dialog, and to move on to the next on the list.
>
> I tried using the create_dialog() function on any new initial requests (an
> INVITE), but as soon as it's routed and another message comes back (for
> example, "ACK"), then we get an error message that no dialog is found for
> it.  I can send a list_dialogs to the FIFO stack after the invite is sent,
> and nothing is listed.
>
> I know in the previous dispatcher module there was a way to hash the
> call-id and include a tag on the sip message -- I could see something
> similar working here, but would be a little more worried about performance
> as I think that would require a database lookup.
>
> Any examples of this module used in stateless mode would be GREATLY
> appreciated.  Thanks a ton, and I'm loving 1.5 and all the new features!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20090624/9c140d77/attachment-0001.htm 


More information about the Users mailing list