1 Feb
2012
1 Feb
'12
12:08 p.m.
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(a)gmail.com>wrote;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