[OpenSIPS-Users] [RFC] Distributed User Location

Fri Apr 5 15:32:00 CEST 2013

Rudy,

You are one step ahead :) - indeed, we need to find the best approach on 
the implementation side (different modules? flags/parameters?).

But the current step is finding the solution : how the distributed 
version of usrloc would look like ?

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 04/05/2013 03:51 PM, Rudy wrote:
> Bogdan,
>
>   As you suggest, there are ways to achieve this now manually with
> custom scripting and glue, it its not very straightforward. What I
> think is the goal would be something drop in ready, that you could
> just enable for distributed location versus normal location.
>
>   The solution may be to fork the registrar and usrloc modules into
> distributed versions of the modules. These would automatically support
> these distributed scenarios by using a combination of things
> discussed, and possibly a forced path flag that would route back to
> the home proxy by modifying the registrar request (perhaps with a path
> to home proxy).
>
>   This way, it would not interfere with existing usage of these modules
> and allow for more flexibility when developing these new ones without
> breaking existing installations.
>
>   What do you guys think?
>
> Thanks in advance,
> --Rudy
> Dynamic Packet
> Toll-Free: 888.929.VOIP ( 8647 )
>
>
> On Fri, Apr 5, 2013 at 8:37 AM, Bogdan-Andrei Iancu<bogdan at opensips.org>  wrote:
>> 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,
>> sip2.mydomain.com ... sipN.mydomain.com, each serving domain 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,
>> 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
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> 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
>> Email: shaheryarkh at googlemail.com
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>