On Tue, Nov 20, 2012 at 4:22 PM, Andrew Mortensen <admor...@isc.upenn.edu> wrote: > > 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.
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 _______________________________________________ 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
