[SR-Users] Time elapsed since previous message.

Alex Balashov abalashov at evaristesys.com
Wed Feb 10 20:47:04 CET 2021


Have you tried drop()ping the end-to-end `487 Request Terminated` reply 
from upstream in a failure_route, and then send_reply() in its place?

-- Alex

On 2/10/21 2:43 PM, David Villasmil wrote:

> Actually I already implemented that timeout, I haven’t asked about that, 
> because I didn’t have any problems with that one.
> 
> I am being asked for that “if a 180 comes within 0.8 seconds, cancel the 
> call and send a 480 to the origination.
> 
> The cancel I got it working thanks to your help. Sending back a 480 to 
> the origination is what’s proving more difficult, I just can’t figure 
> that one out.
> 
> On Wed, 10 Feb 2021 at 19:29, Alex Balashov <abalashov at evaristesys.com 
> <mailto:abalashov at evaristesys.com>> wrote:
> 
>     Wouldn’t it make more sense to just have an aggressive timeout for
>     the “keeping it there” aspect?
> 
>     That is, if, upon receipt of a non-100 1xx message, a final
>     dispositive reply does not follow within X seconds, route-advance to
>     the next provider? This can be accomplished with the
>     t_set_fr/t_reset_fr() technique previously discussed.
> 
>     It sounds like you might be making this unnecessarily complicated.
>     :-) Don’t worry about how quickly they send you the
>     progress/alerting messages; instead, worry about how slowly they
>     send you anything else afterward.
> 
>     The only wrinkle I can see that in that is the caller experience...
> 
>>     Sent from mobile, with due apologies for brevity and errors.
> 
>>     On Feb 10, 2021, at 2:13 PM, David Villasmil
>>     <david.villasmil.work at gmail.com
>>     <mailto:david.villasmil.work at gmail.com>> wrote:
>>
>>     
>>     Some providers have other providers which many times just answer
>>     the call and try to keep it there. It’s a known strategy some
>>     scammers use. Getting a 180/3 in say; 500ms (to a real-life hard
>>     line, is probably one such call.
>>
>>
>>     On Wed, 10 Feb 2021 at 18:52, Raúl Alexis Betancor Santana
>>     <rbetancor at serlink.es <mailto:rbetancor at serlink.es>> wrote:
>>
>>         What is the point of refusing a call that answer with a
>>         100/183 "too quickly" ? ... I don't get the point on that.
>>
>>         Saludos
>>         --
>>         *Raúl Alexis Betancor Santana*
>>         Serlink Telecom S.R.L.U.
>>
>>         ------------------------------------------------------------------------
>>         *De: *"David Villasmil" <david.villasmil.work at gmail.com
>>         <mailto:david.villasmil.work at gmail.com>>
>>         *Para: *"Kamailio (SER) - Users Mailing List"
>>         <sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>>
>>         *Enviados: *Miércoles, 10 de Febrero 2021 9:57:35
>>         *Asunto: *Re: [SR-Users] Time elapsed since previous message.
>>
>>         Hello Alex,
>>         Again thanks.
>>
>>         I'm using that calculation to, when receiving a 180/3, if it
>>         comes in too quickly (i.e. 100ms) i cancel that call, and send
>>         a 480 the the A leg.
>>         I haven't found way of doing this, is this possible at all? I
>>         trired setting a very low t_set_fr(10,10) (0 means set the
>>         default), but that's not working...
>>
>>         Is there a way of doing this?
>>
>>         Thanks!
>>         Regards,
>>
>>         David Villasmil
>>         email: david.villasmil.work at gmail.com
>>         <mailto:david.villasmil.work at gmail.com>
>>         phone: +34669448337
>>
>>
>>         On Tue, Feb 9, 2021 at 3:31 PM David Villasmil
>>         <david.villasmil.work at gmail.com
>>         <mailto:david.villasmil.work at gmail.com>> wrote:
>>
>>             Thanks Alex,
>>
>>             Exactly what I was thinking. Just wondering whether there
>>             was a better way.
>>
>>             Again THANKS!
>>
>>             David
>>
>>             On Tue, 9 Feb 2021 at 14:56, Alex Balashov
>>             <abalashov at evaristesys.com
>>             <mailto:abalashov at evaristesys.com>> wrote:
>>
>>                 Hi,
>>                 You can store the timestamp of the last message of
>>                 interest in a transaction-persistent variable - that
>>                 is, an AVP or XAVP - using $TV():
>>
>>                 https://www.kamailio.org/wiki/cookbooks/5.4.x/pseudovariables#tv_name
>>                 <https://www.kamailio.org/wiki/cookbooks/5.4.x/pseudovariables#tv_name>
>>
>>                 Then, you can do some arithmetic like this to turn the
>>                 difference between two timestamps into milliseconds.
>>                 This is stolen straight from CSRP so adapt to your
>>                 needs. :-)
>>
>>                 	# Log request processing time.
>>
>>                 	$var(cur_time) = $TV(Sn);
>>
>>                 	$var(proc_diff) = (
>>                 		(((
>>                 		  $(var(cur_time){s.select,0,.}{s.int  <http://s.int>}) -
>>                 		  $(avp(proc_start){s.select,0,.}{s.int  <http://s.int>})
>>                 		) * 1000000)
>>                 		+
>>                 		(
>>                 		 $(var(cur_time){s.select,1,.}{s.int  <http://s.int>}) -
>>                 		 $(avp(proc_start){s.select,1,.}{s.int  <http://s.int>})
>>                 		) / 1000) mod 1000
>>                 	);
>>
>>
>>                 — Alex
>>
>>>>                 Sent from my iPad
>>
>>                     On Feb 9, 2021, at 9:40 AM, David Villasmil
>>                     <david.villasmil.work at gmail.com
>>                     <mailto:david.villasmil.work at gmail.com>> wrote:
>>
>>                     Hello all,
>>
>>
>>                     Is it possible to know the elapsed time since the
>>                     previously received message?
>>
>>                     On outgoing calls, I.e: when i get a 180, how long
>>                     did the 100 arrived? Or the INVITE...
>>
>>                     Thanks
>>
>>                     David
>>                     -- 
>>                     Regards,
>>
>>                     David Villasmil
>>                     email: david.villasmil.work at gmail.com
>>                     <mailto:david.villasmil.work at gmail.com>
>>                     phone: +34669448337
>>
>>                     _______________________________________________
>>                     Kamailio (SER) - Users Mailing List
>>                     sr-users at lists.kamailio.org
>>                     <mailto:sr-users at lists.kamailio.org>
>>                     https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>                     <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>>
>>                 _______________________________________________
>>                 Kamailio (SER) - Users Mailing List
>>                 sr-users at lists.kamailio.org
>>                 <mailto:sr-users at lists.kamailio.org>
>>                 https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>                 <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>>
>>             -- 
>>             Regards,
>>
>>             David Villasmil
>>             email: david.villasmil.work at gmail.com
>>             <mailto:david.villasmil.work at gmail.com>
>>             phone: +34669448337
>>
>>
>>         _______________________________________________
>>         Kamailio (SER) - Users Mailing List
>>         sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>>         https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>         <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>>         _______________________________________________
>>         Kamailio (SER) - Users Mailing List
>>         sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>>         https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>         <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>>
>>     -- 
>>     Regards,
>>
>>     David Villasmil
>>     email: david.villasmil.work at gmail.com
>>     <mailto:david.villasmil.work at gmail.com>
>>     phone: +34669448337
>>     _______________________________________________
>>     Kamailio (SER) - Users Mailing List
>>     sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>>     https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>     <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>     _______________________________________________
>     Kamailio (SER) - Users Mailing List
>     sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>     https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>     <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> 
> -- 
> Regards,
> 
> David Villasmil
> email: david.villasmil.work at gmail.com 
> <mailto:david.villasmil.work at gmail.com>
> phone: +34669448337
> 
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> 

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/



More information about the sr-users mailing list