On Tue, Nov 20, 2012 at 5:17 PM, Andrew Mortensen admorten@isc.upenn.edu wrote:
On Nov 20, 2012, at 3:43 PM, Ovidiu Sas osas@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.
I deployed sca and I didn't need to rely on usrloc for clearing up the stale appearances. The call was monitored and based on that the stale appearance was removed. Let's assume that a phone just registered for 1 hour and a call is made. During the call, the power is lost. If you wait for the contact to expire, you will end up with a 1h stale appearance. If you monitor the call/dialog, the stale appearance can be removed much faster.
Another issues that I'm seeing here is if the sca server is behind a registrar, then this setup will not work (registrations are held on a different server). It would be nice to have a parameter to disable usrloc binding. I don't know if usrloc binding is mandatory or not.
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.
As I pointed in my previous e-mail, the sca logic can be kept in one module and the presence built on top of the existing presence infrastructure. The sca module will just need to send PUBLISH messages to the presence server. I built a call-info extension for presence in opensips (I was working with Anca at that point in time) and my goal was (and still is) to port the changes here (but the project was delayed due to other projects).
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.
That is very clever. I really like your idea messing with Replaces header. I know exactly how the special INVITE retrieving a held call looks like. Only the server behind the proxy must support RFC3891. For the phones it should be transparent. I'm looking forward to test your implementation.
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.
I tested mainly with Cisco and Linksys phones (and a few Polycom phones) and everything works great. I didn't had any particular issues with stale appearances. Sometimes, I had issues with CISCO phones connected over WiFi and not receiving notifications and the stale appearance was present only on that set. A new call (made from any other set) cleared up the stale appearance (the new notification sent by the presence server refreshed everything on the phone).
By the way, I don't know what's the meaning of domain in the Call-Info header. I just set it to "127.0.0.1" and the sets are happy with it.
Thanks for your feedback!
Your welcome! Hope you'll find them useful.
Regards, Ovidiu Sas