<div dir="ltr">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.<div>
<br></div><div><div style>In the Super Node module, we will have,</div><div style><br></div><div style>1. one db table to store base node addresses for monitoring the Event.</div><div style>2. one db table to store data received from the Event, lets call it "Event Table".</div>
<div style>3. one process to manage "Event Table", pretty much the same way location table is managed by usrloc module.</div><div style>4. some scripting functions for opensips.cfg, to look up in "Event Table" and do SIP redirect.</div>
<div style>5. some MI functions to manually manage base node table and event table.</div><div style><br></div><div style>In the Base Node module, we will have,</div><div style><br></div><div style>1. module parameters to define address of Super Node and event advertise socket (Super Node will connect to this socket to receive events).</div>
<div style>2. a process to monitor usrloc table, such that as soon as a new user registers, it advertise this to event socket.</div><div style>3. some scripting functions for opensips.cfg, to send call to Super Node if lookup function (from registrar module) fails and in reply route to handle SIP Redirect to send call to destination base node returned by Super Node.</div>
<div style>4. some MI functions etc.</div><div style><br></div><div style>Thank you.</div><div style><br></div><div style><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 5, 2013 at 1:37 PM, Bogdan-Andrei Iancu <span dir="ltr"><<a href="mailto:bogdan@opensips.org" target="_blank">bogdan@opensips.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div bgcolor="#ffffff" text="#000000">
<tt>Hello Muhammad,<br>
<br>
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 ?<br>
<br>
Best regards,</tt><div class="im"><br>
<pre cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a href="http://www.opensips-solutions.com" target="_blank">http://www.opensips-solutions.com</a></pre>
<br></div><div><div class="h5">
On 04/05/2013 04:57 AM, Muhammad Shahzad wrote:
<blockquote type="cite">
<div dir="ltr">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.
<div><br>
</div>
<div>1. We have number of SIP servers running, say <a href="http://sip1.mydomain.com" target="_blank">sip1.mydomain.com</a>,
<a href="http://sip2.mydomain.com" target="_blank">sip2.mydomain.com</a>
... <a href="http://sipN.mydomain.com" target="_blank">sipN.mydomain.com</a>,
each serving domain <a href="http://mydomain.com" target="_blank">mydomain.com</a> and a SIP client
A can select any one of these servers through DNS look-up (or
whatever way possible) and registers to that server. Lets call
these servers as Base Nodes.</div>
<div><br>
</div>
<div>2. Upon successful registration of client A to
server <a href="http://sip1.mydomain.com" target="_blank">sip1.mydomain.com</a>, this
Registrar Node fires an Event, which can be subscribed by a
back-end SIP server, lets call it Super Node. This event will
only contain following things,</div>
<div><br>
</div>
<div> a). User part of all Contact URIs of client A
with Expiry.</div>
<div> b). Registrar Node information e.g. its IP
address + Port.</div>
<div> c). SIP domain of client A. (in case of
multi-domain setup)</div>
<div><br>
</div>
<div>3. Super Node stores this information in some db
back-end (memcache, redis, mysql etc.). This is sort of
back-to-back register process but without SIP or
authentication, since that has already been handled on Based
Node anyway. The Super Node only needs to know which user is
registered on which Base Node e.g. user 1001 is registered on
node <a href="http://sip1.mydomain.com" target="_blank">sip1.mydomain.com</a>, user
1203 is registered on <a href="http://sip6.mydomain.com" target="_blank">sip6.mydomain.com</a> and so
on.</div>
<div><br>
</div>
<div>4. When a SIP client B tries to send INVITE or
MESSAGE or SUBSCRIBE to SIP client A. The SIP request will
arrive on Base Node it is currently registered with, say <a href="http://sip2.mydomain.com" target="_blank">sip2.mydomain.com</a>.
This node will first do local look-up for location of client
A. Upon failure it will forward request to Super Node, which
will do a look-up on Event database and finds that client A is
registered on node <a href="http://sip1.mydomain.com" target="_blank">sip1.mydomain.com</a>, so it
will send SIP redirect response 302 to requester Base Node.
Now the request source node knows the address of request
destination node, where it will send request next and they
both, while acting as independent SIP servers, establish SIP
session between caller and callee. This should work regardless
if both nodes serve same or different SIP domains.</div>
<div><br>
</div>
<div>5. The Super Node will also give us global
presence of all users currently registered to all Base Nodes,
which may be useful for management and monitoring etc.</div>
<div><br>
</div>
<div>
Pros:</div>
<div>1. Completely independent of network topology and
SIP.</div>
<div>2. Will work seamlessly for multi
and federated domains.</div>
<div>3. Scale-able in every direction.</div>
<div>4. Minimal overhead for session establishment.
Once supper node return destination base node address in SIP
redirect response, session will establish directly between
source and destination base node. Further optimizations are
possible, e.g. base node can cache destination base node
returned by supper node for any particular user and avoid
querying super node for recurring SIP sessions.</div>
<div><br>
</div>
<div>Cons: </div>
<div>1. Well, the key problem i can guess is of course
the Event database size and speed, as it will have information
on every user registered to every Base Node. I suggest memory
cache db such as Redis would be idle for this storage.</div>
<div>2. Bandwidth consumed in Event transport. We can
apply compression and make event queues as optimization.</div>
<div><br>
</div>
<div>Comments and suggestions are highly welcome.</div>
<div><br>
</div>
<div>Thank you.</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Apr 4, 2013 at 2:05 PM, Vlad
Paiu <span dir="ltr"><<a href="mailto:vladpaiu@opensips.org" target="_blank">vladpaiu@opensips.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello all,<br>
<br>
We would like to get suggestions and help on the matter of
distributing the user location information.<br>
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<br>
<br>
While now, by using the OpenSIPS trunk, it is possible to
just share the actual usrloc info ( by using the db_cachedb
module and storing the information in a MongoDB cluster ),
you can encounter real-life scenarios where just sharing the
info is not enough, like :<br>
- NAT-ed clients, where only the initial server that
received the Register has the pin-hole open, and thus is the
only server that can relay traffic back to the respective
client<br>
- the user has a SIP client that only accepts traffic
from the server IP that it's currently registered against,
and thus would reject direct traffic from other IPs ( due to
security reasons )<br>
<br>
We would like to implement a true general solution for this
issue, and would appreciate your feedback on this. Also we'd
appreciate if you could share the needs that you would have
from such a distributed user location feature, and the
scenarios that you would use such a feature in real-life
setups.<br>
<br>
<br>
Best Regards,<span><font color="#888888"><br>
<br>
-- <br>
Vlad Paiu<br>
OpenSIPS Developer<br>
<a href="http://www.opensips-solutions.com" target="_blank">http://www.opensips-solutions.com</a><br>
<br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</font></span></blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div><span style="color:rgb(136,136,136);font-size:13px;font-family:arial,sans-serif">Mit freundlichen Grüßen</span></div>
<span style="color:rgb(136,136,136);font-size:13px;font-family:arial,sans-serif">Muhammad Shahzad</span><br style="color:rgb(136,136,136);font-size:13px;font-family:arial,sans-serif">
<span style="color:rgb(136,136,136);font-size:13px;font-family:arial,sans-serif">------------------------------</span><span style="color:rgb(136,136,136);font-size:13px;font-family:arial,sans-serif">-----</span><br style="color:rgb(136,136,136);font-size:13px;font-family:arial,sans-serif">
<span style="color:rgb(136,136,136);font-size:13px;font-family:arial,sans-serif">CISCO Rich Media Communication Specialist (CRMCS)</span><br style="color:rgb(136,136,136);font-size:13px;font-family:arial,sans-serif">
<span style="color:rgb(136,136,136);font-size:13px;font-family:arial,sans-serif">CISCO Certified Network Associate (CCNA)</span><br style="color:rgb(136,136,136);font-size:13px;font-family:arial,sans-serif">
<span style="color:rgb(136,136,136);font-size:13px;font-family:arial,sans-serif">Cell: +49 176 99 83 10 85</span><br style="color:rgb(136,136,136);font-size:13px;font-family:arial,sans-serif">
<span style="color:rgb(136,136,136);font-size:13px;font-family:arial,sans-serif">MSN: </span><a href="mailto:shari_786pk@hotmail.com" style="color:rgb(17,85,204);font-size:13px;font-family:arial,sans-serif" target="_blank">shari_786pk@hotmail.com</a><br style="color:rgb(136,136,136);font-size:13px;font-family:arial,sans-serif">
<span style="color:rgb(136,136,136);font-size:13px;font-family:arial,sans-serif">Email: </span><a href="mailto:shaheryarkh@googlemail.com" style="color:rgb(17,85,204);font-size:13px;font-family:arial,sans-serif" target="_blank">shaheryarkh@googlemail.com</a>
</div>
<pre><fieldset></fieldset>
_______________________________________________
Users mailing list
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
</div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div><span style="color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">Mit freundlichen Grüßen</span></div><span style="color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">Muhammad Shahzad</span><br style="color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<span style="color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">------------------------------</span><span style="color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">-----</span><br style="color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<span style="color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">CISCO Rich Media Communication Specialist (CRMCS)</span><br style="color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<span style="color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">CISCO Certified Network Associate (CCNA)</span><br style="color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<span style="color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">Cell: +49 176 99 83 10 85</span><br style="color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<span style="color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">MSN: </span><a href="mailto:shari_786pk@hotmail.com" style="color:rgb(17,85,204);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)" target="_blank">shari_786pk@hotmail.com</a><br style="color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<span style="color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">Email: </span><a href="mailto:shaheryarkh@googlemail.com" style="color:rgb(17,85,204);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)" target="_blank">shaheryarkh@googlemail.com</a>
</div>