I've been working on a Shared Call Appearances module for the past several months. It implements the Broadsoft SCA feature as laid out in Broadworks SIP Access Side Extensions Interface Specifications document. (Another implementation of the same feature was added to Freeswitch a few years ago, but we didn't want to use Freeswitch.)
We've been testing and improving the module over the last month, and I think it's ready to share. The module is available at GitHub here:
https://github.com/fitterhappier/sca
To date, we've only tested the module with Polycom handsets.
I'm happy to answer questions. I hope this will prove useful for others.
Best, andrew
This looks really awesome. Thanks for sharing On Nov 19, 2012 4:50 PM, "Andrew Mortensen" admorten@isc.upenn.edu wrote:
I've been working on a Shared Call Appearances module for the past several months. It implements the Broadsoft SCA feature as laid out in Broadworks SIP Access Side Extensions Interface Specifications document. (Another implementation of the same feature was added to Freeswitch a few years ago, but we didn't want to use Freeswitch.)
We've been testing and improving the module over the last month, and I think it's ready to share. The module is available at GitHub here:
<https://github.com/fitterhappier/sca>To date, we've only tested the module with Polycom handsets.
I'm happy to answer questions. I hope this will prove useful for others.
Best, andrew _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On Nov 19, 2012, at 4:56 PM, David J david@styleflare.com wrote:
This looks really awesome. Thanks for sharing
Thanks, and you're welcome. I've added very simple installation instructions to the repo.
andrew
On Nov 19, 2012 4:50 PM, "Andrew Mortensen" admorten@isc.upenn.edu wrote: I've been working on a Shared Call Appearances module for the past several months. It implements the Broadsoft SCA feature as laid out in Broadworks SIP Access Side Extensions Interface Specifications document. (Another implementation of the same feature was added to Freeswitch a few years ago, but we didn't want to use Freeswitch.)
We've been testing and improving the module over the last month, and I think it's ready to share. The module is available at GitHub here:
<https://github.com/fitterhappier/sca>To date, we've only tested the module with Polycom handsets.
I'm happy to answer questions. I hope this will prove useful for others.
Best, andrew _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
By the way what versions does this support?
On 11/19/12 5:19 PM, Andrew Mortensen wrote:
On Nov 19, 2012, at 4:56 PM, David J david@styleflare.com wrote:
This looks really awesome. Thanks for sharing
Thanks, and you're welcome. I've added very simple installation instructions to the repo.
andrew
On Nov 19, 2012 4:50 PM, "Andrew Mortensen" admorten@isc.upenn.edu wrote: I've been working on a Shared Call Appearances module for the past several months. It implements the Broadsoft SCA feature as laid out in Broadworks SIP Access Side Extensions Interface Specifications document. (Another implementation of the same feature was added to Freeswitch a few years ago, but we didn't want to use Freeswitch.)
We've been testing and improving the module over the last month, and I think it's ready to share. The module is available at GitHub here:
<https://github.com/fitterhappier/sca>To date, we've only tested the module with Polycom handsets.
I'm happy to answer questions. I hope this will prove useful for others.
Best, andrew _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
It should work with 3.1 or newer. The bulk of our testing was done with 3.2 and 3.3.
andrew
On Nov 19, 2012, at 5:46 PM, David | StyleFlare david@styleflare.com wrote:
By the way what versions does this support?
On 11/19/12 5:19 PM, Andrew Mortensen wrote:
On Nov 19, 2012, at 4:56 PM, David J david@styleflare.com wrote:
This looks really awesome. Thanks for sharing
Thanks, and you're welcome. I've added very simple installation instructions to the repo.
andrew
On Nov 19, 2012 4:50 PM, "Andrew Mortensen" admorten@isc.upenn.edu wrote: I've been working on a Shared Call Appearances module for the past several months. It implements the Broadsoft SCA feature as laid out in Broadworks SIP Access Side Extensions Interface Specifications document. (Another implementation of the same feature was added to Freeswitch a few years ago, but we didn't want to use Freeswitch.)
We've been testing and improving the module over the last month, and I think it's ready to share. The module is available at GitHub here:
<https://github.com/fitterhappier/sca>To date, we've only tested the module with Polycom handsets.
I'm happy to answer questions. I hope this will prove useful for others.
Best, andrew _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Thanks I am going to try build against git master right now.
And test it out.
On 11/19/12 5:49 PM, Andrew Mortensen wrote:
It should work with 3.1 or newer. The bulk of our testing was done with 3.2 and 3.3.
andrew
On Nov 19, 2012, at 5:46 PM, David | StyleFlare david@styleflare.com wrote:
By the way what versions does this support?
On 11/19/12 5:19 PM, Andrew Mortensen wrote:
On Nov 19, 2012, at 4:56 PM, David J david@styleflare.com wrote:
This looks really awesome. Thanks for sharing
Thanks, and you're welcome. I've added very simple installation instructions to the repo.
andrew
On Nov 19, 2012 4:50 PM, "Andrew Mortensen" admorten@isc.upenn.edu wrote: I've been working on a Shared Call Appearances module for the past several months. It implements the Broadsoft SCA feature as laid out in Broadworks SIP Access Side Extensions Interface Specifications document. (Another implementation of the same feature was added to Freeswitch a few years ago, but we didn't want to use Freeswitch.)
We've been testing and improving the module over the last month, and I think it's ready to share. The module is available at GitHub here:
<https://github.com/fitterhappier/sca>To date, we've only tested the module with Polycom handsets.
I'm happy to answer questions. I hope this will prove useful for others.
Best, andrew _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Also quick read at the readme, it looks like it does not support multi-domain setups?
On 11/19/12 5:49 PM, Andrew Mortensen wrote:
It should work with 3.1 or newer. The bulk of our testing was done with 3.2 and 3.3.
andrew
On Nov 19, 2012, at 5:46 PM, David | StyleFlare david@styleflare.com wrote:
By the way what versions does this support?
On 11/19/12 5:19 PM, Andrew Mortensen wrote:
On Nov 19, 2012, at 4:56 PM, David J david@styleflare.com wrote:
This looks really awesome. Thanks for sharing
Thanks, and you're welcome. I've added very simple installation instructions to the repo.
andrew
On Nov 19, 2012 4:50 PM, "Andrew Mortensen" admorten@isc.upenn.edu wrote: I've been working on a Shared Call Appearances module for the past several months. It implements the Broadsoft SCA feature as laid out in Broadworks SIP Access Side Extensions Interface Specifications document. (Another implementation of the same feature was added to Freeswitch a few years ago, but we didn't want to use Freeswitch.)
We've been testing and improving the module over the last month, and I think it's ready to share. The module is available at GitHub here:
<https://github.com/fitterhappier/sca>To date, we've only tested the module with Polycom handsets.
I'm happy to answer questions. I hope this will prove useful for others.
Best, andrew _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On Nov 19, 2012, at 5:53 PM, David | StyleFlare david@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.
andrew
On 11/19/12 5:49 PM, Andrew Mortensen wrote:
It should work with 3.1 or newer. The bulk of our testing was done with 3.2 and 3.3.
andrew
On Nov 19, 2012, at 5:46 PM, David | StyleFlare david@styleflare.com wrote:
By the way what versions does this support?
On 11/19/12 5:19 PM, Andrew Mortensen wrote:
On Nov 19, 2012, at 4:56 PM, David J david@styleflare.com wrote:
This looks really awesome. Thanks for sharing
Thanks, and you're welcome. I've added very simple installation instructions to the repo.
andrew
On Nov 19, 2012 4:50 PM, "Andrew Mortensen" admorten@isc.upenn.edu wrote: I've been working on a Shared Call Appearances module for the past several months. It implements the Broadsoft SCA feature as laid out in Broadworks SIP Access Side Extensions Interface Specifications document. (Another implementation of the same feature was added to Freeswitch a few years ago, but we didn't want to use Freeswitch.)
We've been testing and improving the module over the last month, and I think it's ready to share. The module is available at GitHub here:
<https://github.com/fitterhappier/sca>To date, we've only tested the module with Polycom handsets.
I'm happy to answer questions. I hope this will prove useful for others.
Best, andrew _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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@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.
Would you consider adding it to main git repository and maintaining it there?
Cheers, Daniel
andrew
On 11/19/12 5:49 PM, Andrew Mortensen wrote:
It should work with 3.1 or newer. The bulk of our testing was done with 3.2 and 3.3.
andrew
On Nov 19, 2012, at 5:46 PM, David | StyleFlare david@styleflare.com wrote:
By the way what versions does this support?
On 11/19/12 5:19 PM, Andrew Mortensen wrote:
On Nov 19, 2012, at 4:56 PM, David J david@styleflare.com wrote:
This looks really awesome. Thanks for sharing
Thanks, and you're welcome. I've added very simple installation instructions to the repo.
andrew
On Nov 19, 2012 4:50 PM, "Andrew Mortensen" admorten@isc.upenn.edu wrote: I've been working on a Shared Call Appearances module for the past several months. It implements the Broadsoft SCA feature as laid out in Broadworks SIP Access Side Extensions Interface Specifications document. (Another implementation of the same feature was added to Freeswitch a few years ago, but we didn't want to use Freeswitch.)
We've been testing and improving the module over the last month, and I think it's ready to share. The module is available at GitHub here:
<https://github.com/fitterhappier/sca>To date, we've only tested the module with Polycom handsets.
I'm happy to answer questions. I hope this will prove useful for others.
Best, andrew _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On Nov 20, 2012, at 4:08 AM, Daniel-Constantin Mierla miconda@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@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.
Would you consider adding it to main git repository and maintaining it there?
Yes, that would be great. 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.
Best, andrew
On 11/20/12 8:43 PM, Andrew Mortensen wrote:
On Nov 20, 2012, at 4:08 AM, Daniel-Constantin Mierla miconda@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@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
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
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.
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@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@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@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
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
On Nov 20, 2012, at 3:16 PM, Daniel-Constantin Mierla miconda@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@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@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
On Tue, Nov 20, 2012 at 4:22 PM, Andrew Mortensen admorten@isc.upenn.edu wrote:
On Nov 20, 2012, at 3:16 PM, Daniel-Constantin Mierla miconda@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@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@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.
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
On 11/20/12 10:41 PM, Ovidiu Sas wrote:
On Tue, Nov 20, 2012 at 4:22 PM, Andrew Mortensen admorten@isc.upenn.edu wrote:
On Nov 20, 2012, at 3:16 PM, Daniel-Constantin Mierla miconda@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@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@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.
Cheers, Daniel
19 nov 2012 kl. 23:19 skrev Andrew Mortensen admorten@isc.upenn.edu:
On Nov 19, 2012, at 4:56 PM, David J david@styleflare.com wrote:
This looks really awesome. Thanks for sharing
Thanks, and you're welcome. I've added very simple installation instructions to the repo.
Do we have any idea on the licensing for this? They used to be restrictive, which is why Asterisk doesn't support it. I don't like signing NDAs.
/O
On Nov 20, 2012, at 2:11 AM, "Olle E. Johansson" oej@edvina.net wrote:
19 nov 2012 kl. 23:19 skrev Andrew Mortensen admorten@isc.upenn.edu:
On Nov 19, 2012, at 4:56 PM, David J david@styleflare.com wrote:
This looks really awesome. Thanks for sharing
Thanks, and you're welcome. I've added very simple installation instructions to the repo.
Do we have any idea on the licensing for this? They used to be restrictive, which is why Asterisk doesn't support it. I don't like signing NDAs.
The work in the module I've written is based on an old document defining the event packages that I found via Google at SIPfoundry. No NDA was required.
As it happens, it's the same document that you linked to on the sip-implementors list:
https://lists.cs.columbia.edu/pipermail/sip-implementors/2011-July/027503.ht...
I believe it's also the same document that FreeSWITCH used when adding their implementation of the feature, which they released in early 2010. FreeSWITCH's implementation of SCA is available in their public github source repository.
Best, andrew
-
Andrew Mortensen -
Daniel-Constantin Mierla -
David J -
David | StyleFlare
-
Olle E. Johansson -
Ovidiu Sas