Hello Adrian,
From resources point of view, this is how I see things :
1) media - the node which is contacted by user (via DNS) should take
care of the media (unrelated to registration)
2) registration - you can do it on the access node (used by user to
access the service), or you can use
Bogdan,
As David described, we use a similar memcached setup with script glue
and I think these are becoming fairly common when working in larger
scales. What would be great would be for the distributed location /
registrar modules to do most if not all of this internally. Depending
on what
Just a correction for David, in my proposal SIP response 302 is returned by
super node to base node to redirect base node to correct destination base
node that has destination UA registered on it. This 302 response will not
and should not be transmitted to endpoint UA (neither source nor
I concur with Adrian, I don't think geo-distribution is as important for
SIP signaling as it is for the media flow. The rest of this e-mail does
not address geo-distribution.
In regards to your last e-mail Bogdan, we do something similar to the
system you describe, but in our case the
Hi,
Putting together what you said and what Adrian and Muhammad said :
Actually we may have a distributed USRLOC for 2 purposes: geo
distribution and load distribution - how they are approach it is a bit
different.
But first let's look into the common part (for the 2 cases) : IMHO, in
both
I am running for years servers distributed in different countries part of the
same service and nobody complained about the latency of signaling but they
complained about media. This idea of geo-distribution is more about media path
optimization and automatic recovery in case of connectivity
Hello Adrian,
The actual question is IF there is SOMETHING that can be done directly
in the usrloc module to help with distributed scenario (to have some
built-in functionality to have an auto-of-the-box solution). I'm fully
aware you can combine the existing module with other kind of
Hello Muhammad,
Your approach is the correct one (from SIP perspective) IMHO. But there
are questions on the implementation side too - like the Super Node is
just a storage or it should have SIP capabilities? How much of this
behavior should be hardcoded in the registrar + usrloc module ?
Rudy,
You are one step ahead :) - indeed, we need to find the best approach on
the implementation side (different modules? flags/parameters?).
But the current step is finding the solution : how the distributed
version of usrloc would look like ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS
Well, i am not much familiar with internals of opensips, i.e. its core and
modules and how they interact with each other. But as an abstract idea, i
suggest that both Base Node and Super Node should be opensips modules. No
change in standard registrar or usrloc modules are actually needed.
In the
Everyone,
Before we get too off topic, I think the goal should be to design
something truly distributed. This would be more like what Adrian
suggested and less like a super node / slave node scenario. The nodes
should be able to coordinate amongst themselves, again, similar to the
docs Adrian
Hello all,
We would like to get suggestions and help on the matter of distributing
the user location information.
Extending the User Location with a built-in distributed support is not
straight forward - it is not about simply sharing data - as it is really
SIP dependent and network limited
Well at 5 am in the morning while thinking on this topic the only thing
ringing in my mind is a mechanism similar to IP to IP Gateway. Here is the
main concept.
1. We have number of SIP servers running, say sip1.mydomain.com,
sip2.mydomain.com ... sipN.mydomain.com, each serving domain
Hello Vlad,
We developed such a solution and is operational since 2005 but not in the open
source domain. The start point was P2P protocols used for file sharing. Is less
of a SIP server issue (we used stock OpenSER and stock OpenSIPS for years) but
rather a generic self-organizing network
14 matches
Mail list logo
