[SR-Users] Shared Call Appearances module

[Daniel-Constantin Mierla]

On 11/20/12 8:43 PM, Andrew Mortensen wrote:
> On Nov 20, 2012, at 4:08 AM, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
>
>> Hello,
>>
>> thank for contribution!
>>
>> On 11/20/12 12:16 AM, Andrew Mortensen wrote:
>>> On Nov 19, 2012, at 5:53 PM, David | StyleFlare <david at styleflare.com> wrote:
>>>
>>>> Also quick read at the readme, it looks like it does not support multi-domain setups?
>>> Not yet, no. I don't think it would take much work, though.
>> I see it binds to usrloc, what information needs from there? We have two such modules right now, it would be good to make it work with both, kamailio's one has more features in regard to GRUU and partial outbound extensions.
> It's registering for contact expiration and deletion events. The callback terminates subscriptions for the expired/deleted contact. This should probably be configurable.

Ok, so it is about when a contact record in removed from location.

Just to avoid misunderstandings, do you consider to make configurable 
this termination of subscriptions based on location?

Also, you need only the AoR and contact address in a callback for 
location record removal event (un-registration or registration 
expiration), right?

>
>> Would you consider adding it to main git repository and maintaining it there?
> Yes, that would be great.

We will prepare write access for you.

>   Would you prefer to have it in modules? I started work on it in modules_s, but there's no particular reason it has to stay there.
To make it work with both variants of usrloc modules, I think it 
requires some split of the code. IIRC, both modules still use same names 
for structures, so including files from both of them will fail.

One solutions I am thinking of is to add two small modules, one that 
binds to usloc(k) and the other to usrloc(s). Each of these two modules 
will export a function that allow registering callbacks for execution 
when a location record expires, giving the aor, contact and event type. 
The existing module will use the intermediate module instead of directly 
binding to usrloc structures.

Usrloc module from kamailio has more enhancements in regards to standard 
extensions for location services, still it lacks the feature of being 
able to store variables per contact record. It is the reason that kept 
back the removal (upon merging) of usrloc module from ser. The solution 
with intermediary modules should work until we have a merged usrloc module.

What do you think about this proposal?

Cheers,
Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda