On 11/20/12 10:41 PM, Ovidiu Sas wrote:
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.
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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________
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
