<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body 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><br>
<pre class="moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="moz-txt-link-freetext" href="http://www.opensips-solutions.com">http://www.opensips-solutions.com</a></pre>
<br>
On 04/05/2013 04:57 AM, Muhammad Shahzad wrote:
<blockquote
cite="mid:CAFZQphz+QaKpJyxav2L+76_w-6GpOyXv3eCn2tPOPaT51X0DPA@mail.gmail.com"
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 style="">1. We have number of SIP servers running, say <a
moz-do-not-send="true" href="http://sip1.mydomain.com">sip1.mydomain.com</a>,
<a moz-do-not-send="true" href="http://sip2.mydomain.com">sip2.mydomain.com</a>
... <a moz-do-not-send="true" href="http://sipN.mydomain.com">sipN.mydomain.com</a>,
each serving domain <a moz-do-not-send="true"
href="http://mydomain.com">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 style=""><br>
</div>
<div style="">2. Upon successful registration of client A to
server <a moz-do-not-send="true"
href="http://sip1.mydomain.com">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 style=""><br>
</div>
<div style=""> a). User part of all Contact URIs of client A
with Expiry.</div>
<div style=""> b). Registrar Node information e.g. its IP
address + Port.</div>
<div style=""> c). SIP domain of client A. (in case of
multi-domain setup)</div>
<div style=""><br>
</div>
<div style="">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 moz-do-not-send="true"
href="http://sip1.mydomain.com">sip1.mydomain.com</a>, user
1203 is registered on <a moz-do-not-send="true"
href="http://sip6.mydomain.com">sip6.mydomain.com</a> and so
on.</div>
<div style=""><br>
</div>
<div style="">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
moz-do-not-send="true" href="http://sip2.mydomain.com">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 moz-do-not-send="true"
href="http://sip1.mydomain.com">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 style=""><br>
</div>
<div style="">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 style=""><br>
</div>
<div style="">
Pros:</div>
<div style="">1. Completely independent of network topology and
SIP.</div>
<div style="">2. Will work seamlessly for multi
and federated domains.</div>
<div style="">3. Scale-able in every direction.</div>
<div style="">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 style=""><br>
</div>
<div style="">Cons: </div>
<div style="">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 style="">2. Bandwidth consumed in Event transport. We can
apply compression and make event queues as optimization.</div>
<div style=""><br>
</div>
<div style="">Comments and suggestions are highly welcome.</div>
<div style=""><br>
</div>
<div style="">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 moz-do-not-send="true"
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 class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Vlad Paiu<br>
OpenSIPS Developer<br>
<a moz-do-not-send="true"
href="http://www.opensips-solutions.com"
target="_blank">http://www.opensips-solutions.com</a><br>
<br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a moz-do-not-send="true"
href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a moz-do-not-send="true"
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-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 moz-do-not-send="true"
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 moz-do-not-send="true"
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>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
</body>
</html>