[sr-dev] K|S usrloc merge

Jason Penton jason.penton at gmail.com
Wed Feb 1 12:08:18 CET 2012


okay, i like the 'usrloc-ng' approach. Will see what we can do.

Cheers
Jason

On Wed, Feb 1, 2012 at 1:04 PM, Daniel-Constantin Mierla
<miconda at gmail.com>wrote:

> Hello,
>
>
> On 2/1/12 11:50 AM, Jason Penton wrote:
>
>> Daniel, you will probably be most interested in this based on yesterday's
>> dev chat....
>>
>> Following the discussion from the dev irc yesterday re. usrloc
>> requirements:
>>
>> To summarise the functionality required for GRUU - unique id (for you)
>> and custom subscriber data (for us). As you mentioned yesterday, S version
>> of usrloc has this particular functionality. After a brief look at
>> S-version of usrloc this morning, I have to say I prefer it. Mainly because
>> of the way it handles urecords and ucontacts separately. In K-version - a
>> urecord structure really only exists if there is a contact. There are more
>> deadly implications when in DB mode where a static urecord structure is
>> built on demand. IMHO, I think we should use S module as the basis of a
>> merge?
>>
>> I'd be interested in yours/other interested members' input.
>>
> I haven't looked at specific implementations, just some overview to see
> what missing features are in one or the other. I think k version of
> usrloc/registrar pair has more on db modes and record matching (call-id,
> etc...), branch flags, callbacks for pua_usrloc, $ulc(...) pseduo-variable
> class. s version has a uid, per contact attributes, sip-instance support
> and implements DB2 API which unfortunately not implemented across all db
> connectors, thus limiting the backends. So the merge should preserve the
> functionalities from both, looks like going to be a bit of effort to do it.
> If you want to start, I may help, eventually contributing some parts or
> during the design process. Starting from one or the other, is a matter of
> developer preference -- can be started from scratch, like usrloc-ng :-),
> taking from each of existing "only the good parts".
>
> Cheers,
> Daniel
>
>  --
>> Daniel-Constantin Mierla -- http://www.asipto.com
>> http://linkedin.com/in/miconda -- http://twitter.com/miconda
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20120201/aae791c7/attachment.htm>


More information about the sr-dev mailing list