[OpenSIPS-Users] [RFC] Distributed User Location

Fri Apr 5 14:37:36 CEST 2013

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 <vladpaiu at opensips.org 
> <mailto:vladpaiu at 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 at lists.opensips.org <mailto:Users at 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_786pk at hotmail.com <mailto:shari_786pk at hotmail.com>
> Email: shaheryarkh at googlemail.com <mailto:shaheryarkh at googlemail.com>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20130405/17629db5/attachment-0001.htm>