[SR-Users] Shared Call Appearances module

[Andrew Mortensen]

On Nov 20, 2012, at 3:43 PM, Ovidiu Sas <osas at voipembedded.com> wrote:

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

Yes, that's good point. However, if the phone goes off-line instead of unregistering, the contact's registration will expire, and no unsubscribe will take place. As I mentioned in my reply to Daniel, I'm most concerned about catching this so I can release any appearances seized by the expired/deleted contact, and notify other members of the group. I'm certainly open to alternatives.

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

We've worked extensively with the existing presence & pua modules, albeit primarily dialog;sla using OpenSIPS behind the proxy. (Thanks, Anca!)

SCA's unusual entanglement with call processing made me hesitate about building on top of the existing presence module. For a first pass, I also felt working with an entirely distinct module gave me more control and transparency during development of a very loosely documented event package, especially as I became more familiar with the available API.

I don't have any objection to revisiting design decisions, of course. I'm sure the module will continue to evolve, and it would be nice to eliminate redundancy if possible.

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

No B2BUAs are involved.

The INVITE retrieving a call held by another member of an SCA group has a particular set of characteristics: RURI, To and From URIs are all the SCA AoR; new unconfirmed dialog (no to-tag); and a Call-Info header referring to the index of the held call. The module detects this type of INVITE, looks up the dialog associated with the information in the Call-Info header, and injects a Replaces header with the dialog of the held call before relaying it to the remote party. The remote party must support RFC3891. I've only worked with Polycoms and Cisco gateways to this point, and both do support that RFC. 

I'm very interested in hearing from users with Cisco (and Snom and Aastra?) SCA setups. I have no doubt they'll find bugs resulting from assumptions I've made in the code because I've only tested with Polycom, not least the dependency on RFC3891 support.

Thanks for your feedback!

Best,
andrew



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