[SR-Users] Intermittent delays relaying BYE (up to 1s)

[Lewis Hutchinson]

Thanks for everyone's help on this, it turns out it was something as simple as a missing > 0 in the code which caused the below and sometimes resulted in noticeable delay / BYE retransmission. I suspect this would have caused issues for any within dialog messages with no SDP so glad it is resolved now.

INFO: app_python3 [apy_kemi.c:1820]: sr_apy_kemi_exec_func(): alert - action KSR.rtpengine.rtpengine_manage(...) took too long [1003089 ms] (file:(null)<file://(null)> func:(null) line:252)

Thanks for the help tracking this down, it was proving a bit of a pain but a fresh pair of eyes can see things familiar ones sometimes cannot.


Lewis

From: Daniel-Constantin Mierla <miconda at gmail.com>
Sent: 31 August 2022 11:21
To: Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>; Lewis Hutchinson <lewis.hutchinson at missionlabs.co.uk>
Subject: Re: [SR-Users] Intermittent delays relaying BYE (up to 1s)


First, most of the module functions return negative or positive integer values, not boolean. You have to check with <0 for what's usually false in native kamailio.cfg if conditions and >0 for true.

Then, also double check it does not execute it via a different config path, like the branch route callback (which happens in the default native kamailio.org).

Cheers,
Daniel
On 31.08.22 12:00, Lewis Hutchinson wrote:

Ok so making progress but still a little confused, hopefully this forum can shed some light on this behaviour.

Using the hints provided (thanks all so far) and the latency logging from the cookbook I have managed to isolate the issue down to RTPengine introducing the delay.

INFO: app_python3 [apy_kemi.c:1820]: sr_apy_kemi_exec_func(): alert - action KSR.rtpengine.rtpengine_manage(...) took too long [1003089 ms] (file:(null)<file://(null)> func:(null) line:252)

What is confusing is, I don't believe this block should be being called.

when the BYE is triggered, it routes to ksr_route_withindlg

        # handle requests within SIP dialogs

        if self.ksr_route_withindlg(msg)==-255 :

            return 1


from within the ksr_route_withindlg a check is done to see if any RTPengine work needs doing

    # Handle requests within SIP dialogs

    def ksr_route_withindlg(self, msg):

        if KSR.siputils.has_totag()<0 :

            return 1



        # RTPEngine handling for UPDATES & reINVITES with sdp

        if self.ksr_route_rtpengine(msg) == -255:

            return 1


RTPengine is configured in a way to step in whenever there is an SDP present based on Content-Type: application/sdp

    # RTPengine handle anything with SDP

    def ksr_route_rtpengine(self, msg):

        if KSR.textops.has_body_type("application/sdp"):

           KSR.rtpengine.rtpengine_manage(

               "RTP/AVP replace-session-connection replace-origin ICE=remove")



        return 1


What I can understand is why is this being called and erroring introducing the delay when there is no Content-Type: application/sdp in a BYE ???


As a quick fix I have put this in which stops the problem (I am sure there is better ways to handle this but for now this works in a DEV environment)

    def ksr_route_rtpengine(self, msg):

        if KSR.is_BYE():

           return 1



        if KSR.textops.has_body_type("application/sdp"):

           KSR.rtpengine.rtpengine_manage(

               "RTP/AVP replace-session-connection replace-origin ICE=remove")



        return 1

Can anyone see why this would occur? Why is sr_apy_kemi_exec_func(): alert - action KSR.rtpengine.rtpengine_manage(...) even being called for this BYE ? when there is no Content-Type: application/sdp




Lewis







__________________________________________________________

Kamailio - Users Mailing List - Non Commercial Discussions

  * sr-users at lists.kamailio.org<mailto:sr-users at lists.kamailio.org>

Important: keep the mailing list in the recipients, do not reply only to the sender!

Edit mailing list options or unsubscribe:

  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.kamailio.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsr-users&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk%7C10e8909d9b5f4cc686b608da8b3a889a%7C97c26f550a7a4661bd8f7b43b50d3f2b%7C0%7C0%7C637975380758802801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BFCy1BtWR11lUNNnaRlM%2FO26a2vrujKs%2BEE90ClJQ%2Fw%3D&reserved=0>

--

Daniel-Constantin Mierla -- www.asipto.com<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.asipto.com%2F&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk%7C10e8909d9b5f4cc686b608da8b3a889a%7C97c26f550a7a4661bd8f7b43b50d3f2b%7C0%7C0%7C637975380758802801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=d9wW05V47HnLJnW1DZmOqCjzqv9IPMmeHxD%2B7YKJFDo%3D&reserved=0>

www.twitter.com/miconda<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitter.com%2Fmiconda&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk%7C10e8909d9b5f4cc686b608da8b3a889a%7C97c26f550a7a4661bd8f7b43b50d3f2b%7C0%7C0%7C637975380758802801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rhKynlluDv46CG2RZBNHwzPdMZnVIauAkCPMXhcmZoM%3D&reserved=0> -- www.linkedin.com/in/miconda<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fmiconda&data=05%7C01%7Clewis.hutchinson%40missionlabs.co.uk%7C10e8909d9b5f4cc686b608da8b3a889a%7C97c26f550a7a4661bd8f7b43b50d3f2b%7C0%7C0%7C637975380758802801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2TjlFBQO6wIiJyjCxc4KadWf3pj16mLy1jipVDTH46A%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20220831/a16f4a00/attachment.htm>