[SR-Users] Shared Call Appearances module

[Ovidiu Sas]

Hello Andrew,

First of all, thank you for sharing your work.
I was following this thread and I have a couple of questions.  Why do
you need to bind to the usrloc module? The subscription itself should
be sufficient because if a phone will unregister, it will also
unsubscribe, which leads me to the following question: why not add a
new dedicated module for call-info presence and reuse the existing
infrastructure from kamailio for handling subscriptions/presence.  In
this case, your module should just push PUBLISH events to the presence
server and the server will automatically send out notifications for
subscribers that subscribed to call-info events.

Based on your README file, you inspect SIP requests/replies and based
on the presence of the call-info header, you create call-info events.
This is great for sharing the appearances between phones, but how do
you perform the retrieval of a call that was put on hold?  Are you
using a dedicated B2BUA behind kamailio?

Regards,
Ovidiu Sas

-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

On Tue, 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?
>
> 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
>