1 Feb
2012
1 Feb
'12
6:04 a.m.
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