1 Feb
2012
1 Feb
'12
5:50 a.m.
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.
Cheers
Jason
1 Feb
1 Feb
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
6:08 a.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
4713
days inactive
4713
days old
2 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Jason Penton