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 ?
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 04/05/2013 04:57 AM, Muhammad Shahzad wrote:
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
<http://sip1.mydomain.com>, sip2.mydomain.com
<http://sip2.mydomain.com> ... sipN.mydomain.com
<http://sipN.mydomain.com>, each serving domain mydomain.com
<http://mydomain.com> 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.
2. Upon successful registration of client A to server
sip1.mydomain.com <http://sip1.mydomain.com>, 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,
a). User part of all Contact URIs of client A with Expiry.
b). Registrar Node information e.g. its IP address + Port.
c). SIP domain of client A. (in case of multi-domain setup)
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
sip1.mydomain.com <http://sip1.mydomain.com>, user 1203 is registered
on sip6.mydomain.com <http://sip6.mydomain.com> and so on.
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 sip2.mydomain.com <http://sip2.mydomain.com>.
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
sip1.mydomain.com <http://sip1.mydomain.com>, 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.
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.
Pros:
1. Completely independent of network topology and SIP.
2. Will work seamlessly for multi and federated domains.
3. Scale-able in every direction.
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.
Cons:
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.
2. Bandwidth consumed in Event transport. We can apply compression and
make event queues as optimization.
Comments and suggestions are highly welcome.
Thank you.
On Thu, Apr 4, 2013 at 2:05 PM, Vlad Paiu <vladp...@opensips.org
<mailto:vladp...@opensips.org>> wrote:
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
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 :
- 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
- 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 )
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.
Best Regards,
--
Vlad Paiu
OpenSIPS Developer
http://www.opensips-solutions.com
_______________________________________________
Users mailing list
Users@lists.opensips.org <mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Mit freundlichen Grüßen
Muhammad Shahzad
-----------------------------------
CISCO Rich Media Communication Specialist (CRMCS)
CISCO Certified Network Associate (CCNA)
Cell: +49 176 99 83 10 85
MSN: shari_78...@hotmail.com <mailto:shari_78...@hotmail.com>
Email: shaherya...@googlemail.com <mailto:shaherya...@googlemail.com>
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
