[OpenSIPS-Devel] [OpenSIPS-Users] [RFC] Distributed User Location

Muhammad Shahzad shaheryarkh at gmail.com
Fri Apr 5 03:57:24 CEST 2013


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,
sip2.mydomain.com ... sipN.mydomain.com, each serving domain
mydomain.comand 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,
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, user 1203
is registered on 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. 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, 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> 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 <http://www.opensips-solutions.com>
>
>
> ______________________________**_________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-**bin/mailman/listinfo/users<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
Email: shaheryarkh at googlemail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130405/8922562e/attachment-0001.htm>


More information about the Devel mailing list