[SR-Users] Shared Call Appearances module

Daniel-Constantin Mierla miconda at gmail.com
Tue Nov 20 22:56:10 CET 2012

On 11/20/12 10:41 PM, Ovidiu Sas wrote:
> On Tue, Nov 20, 2012 at 4:22 PM, Andrew Mortensen
> <admorten at isc.upenn.edu> wrote:
>> 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.
> For clearing appearance state, you should rely on the dialog module
> and register a callback on the dialog module. When a dialog expires,
> you can clear up the stale appearances.
> Also, by enabling the sst module, you can have a tight control over
> the duration of the dialog.
> This will make the implementation cleaner and more robust.
I will not jump to such conclusions.

While dialog module is designed to track active calls, does not mean 
everything has to be on top of it. Just for example, dispatcher module 
has an embedded lightweight call tracking system.

No idea here what the broadsoft extensions require, afaik, there were 
some custom specs. It is no problem to have a dedicated dialog tracking 
system that is better designed for a particular functionality. We do 
have other duplicated systems, for example least cost routing, nat 
traversal, a.s.o.

Also, optimizations and reuse of other parts can be done later if found 
to be better ways.


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

More information about the sr-users mailing list