[OpenSIPS-Users] [RFC] Distributed User Location
Bogdan-Andrei Iancu
bogdan at opensips.org
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>
More information about the Users
mailing list