On Nov 20, 2012, at 3:16 PM, Daniel-Constantin Mierla <mico...@gmail.com> wrote:
> > On 11/20/12 8:43 PM, Andrew Mortensen wrote: >> On Nov 20, 2012, at 4:08 AM, Daniel-Constantin Mierla <mico...@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 <da...@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 _______________________________________________ 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
