From: sr-users-request(a)lists.sip-router.org Subject: sr-users Digest, Vol 90, Issue 72 To: sr-users(a)lists.sip-router.org Date: Wed, 21 Nov 2012 08:58:40 +0100 Send sr-users mailing list submissions to sr-users(a)lists.sip-router.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users or, via email, send a message with subject or body 'help' to sr-users-request(a)lists.sip-router.org You can reach the person managing the list at sr-users-owner(a)lists.sip-router.org When replying, please edit your Subject line so it is more specific than "Re: Contents of sr-users digest..." Today's Topics: 1. Re: Shared Call Appearances module (Daniel-Constantin Mierla) 2. Re: Shared Call Appearances module (Andrew Mortensen) 3. Re: LCR weight (Juha Heinanen) 4. problem with $time Pseudo-Variables on 3.3.2 (Uri Shacked) 5. Re: Dialog module not decrementing profile size (Grant Bagdasarian) ---------------------------------------------------------------------- Message: 1 Date: Tue, 20 Nov 2012 22:56:10 +0100 From: Daniel-Constantin Mierla <miconda(a)gmail.com> Subject: Re: [SR-Users] Shared Call Appearances module To: Ovidiu Sas <osas(a)voipembedded.com> Cc: "SIP Router - Kamailio \(OpenSER\) and SIP Express Router \(SER\) - Users Mailing List" <sr-users(a)lists.sip-router.org> Message-ID: <50ABFC7A.2070602(a)gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 11/20/12 10:41 PM, Ovidiu Sas wrote: 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 ------------------------------ Message: 2 Date: Tue, 20 Nov 2012 17:17:38 -0500 From: Andrew Mortensen <admorten(a)isc.upenn.edu> Subject: Re: [SR-Users] Shared Call Appearances module To: Ovidiu Sas <osas(a)voipembedded.com> Cc: "SIP Router - Kamailio \(OpenSER\) and SIP Express Router \(SER\) - Users Mailing List" <sr-users(a)lists.sip-router.org> Message-ID: <65EAE745-8966-4848-870E-6A50246E0AB7(a)isc.upenn.edu> Content-Type: text/plain; charset=iso-8859-1 On Nov 20, 2012, at 3:43 PM, Ovidiu Sas <osas(a)voipembedded.com> wrote: 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. 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. 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 ------------------------------ Message: 3 Date: Wed, 21 Nov 2012 01:04:52 +0200 From: Juha Heinanen <jh(a)tutpro.com> Subject: Re: [SR-Users] LCR weight To: "SIP Router - Kamailio \(OpenSER\) and SIP Express Router \(SER\) - Users Mailing List" <sr-users(a)lists.sip-router.org> Message-ID: <20652.3220.931000.738348(a)sip.test.fi> Content-Type: text/plain; charset=us-ascii Camila Troncoso writes: you have to figure that out yourself using the script referenced in readme. -- juha ------------------------------ Message: 4 Date: Wed, 21 Nov 2012 09:55:17 +0200 From: Uri Shacked <ushacked(a)gmail.com> Subject: [SR-Users] problem with $time Pseudo-Variables on 3.3.2 To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List" <sr-users(a)lists.sip-router.org> Message-ID: <CAMMbDhQn1r_ke72-u2is8MyRXUV6KkLnZqYwxL5eZG44yYG_2Q(a)mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Hi, I upgraded to 3.3.2 On 3.2 i used the variable $time() to get the current time for some process. Every 2 minutes a RTIMER process started, checked the $time(hour) and $time(min) and on a certain time executed something. This process stopped working on 3.3.2 When i debug, i see that the $time() variable keeps on giving me the same hour and minute that was given on the first run. Meaning the $time() variable does not give the current time. I notice also that the $Ts that on 3.2 gave a current time stopped doing it and $TS does it now.... Any help here? Is it OK and i need to check time another way? Or something in the $time() has changed...? Thanks, Uri