[SR-Users] Shared Call Appearances module

[Andrew Mortensen]

On Nov 20, 2012, at 3:16 PM, Daniel-Constantin Mierla <miconda at gmail.com> wrote:

> 
> 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?

Yes. I can imagine a setup where the location data wouldn't be saved on the host handling SCA.

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

Correct, although Ovidiu makes a good point about (well-behaved) clients unsubscribing at the time of unregistration. In registering for usrloc callbacks, I'm trying to handle a couple problems. First, I'd like to avoid unnecessarily sending and retransmitting NOTIFYs to offline clients. More importantly, I want to be able to hear about expired registrations so I can clear appearance state on the rest of the subscribers.

>>> 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.

Thanks!

>>  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?

I think that would work, especially if it helps bring us closer to a merged usrloc module. I'm not sure it's necessary purely for the sake of the sca module.

Best,
andrew